Florent Kermarrec | 17 Sep 18:25 2014
Picon

[M-Labs devel] [PATCH] Migen: add reverse to Pack/Unpack and add packet support for Sink and Source

Hi,

please find attached some patchs.

It will be fine to have packet support on Sink and Source in Migen since it's very useful on lots of designs. I've also added __getattr__ to _Endpoint to be able to access directly Sink and Source elements (I find more practical to use obj.elt instead of obj.payload.elt). If we really want to be sure that the user will not use specific keywords like "stb", "ack", "payload", "sop", "eop" in payload, we can add a check on _make_m2s.

If you are OK to merge that, I will have others modules using packets that we can integrate to Migen: Crossbar, Dispatcher, Arbiter, CRCChecker/CRCInserter, etc...

I'd also like to remove use of DataFlowGraph on simple examples (ex: DMAReadController, DMAWriteController) by using only packetized Sink and Source and Record.connect(). I really think DataFlowGraph make things really difficults to understand on simple examples (and I think even "complex" examples can be described without DataFlowGraph). Would you be OK with that?

Thanks,

Florent
<div><div dir="ltr">
<span>Hi,</span><div><br></div>
<div>please find attached some patchs.</div>
<div><br></div>
<div>It will be fine to have packet support on Sink and Source in Migen since it's very useful on lots of designs. I've also added __getattr__ to _Endpoint to be able to access directly Sink and Source elements (I find more practical to use obj.elt instead of obj.payload.elt). If we really want to be sure that the user will not use specific keywords like "stb", "ack", "payload", "sop", "eop" in payload, we can add a check on&nbsp;_make_m2s.</div>
<div><br></div>
<div>If you are OK to merge that, I will have others modules using packets that we can integrate to Migen: Crossbar, Dispatcher, Arbiter, CRCChecker/CRCInserter, etc...</div>
<div><br></div>
<div>I'd also like to remove use of&nbsp;DataFlowGraph on simple examples (ex:&nbsp;DMAReadController,&nbsp;DMAWriteController) by using only packetized Sink and Source and Record.connect(). I really think DataFlowGraph make things really difficults to understand on simple examples (and I think even "complex" examples can be described without DataFlowGraph). Would you be OK with that?</div>
<div><br></div>
<div>Thanks,</div>
<div><br></div>
<div>Florent</div>
</div></div>
Poul Laurids W. Larsen | 16 Sep 14:32 2014
Picon

[M-Labs devel] realtime trail/echo/RecursiveOPS for lightwriting

Hello M-Labs, Sebastian and others!

Can You help us find a device that can make realtime trails or overlays without over expose! 

I found the Mixxeo and it looks very interesting! It might be able to do what we are seeking! a piece of
hardware that when connected to cam/hdmi-OUT it will apply realtime processing of videostream/signal
with effects of “building up” the final result/picture (2000-3000frms is the hardcore version if
possible)! We often use up to 2mins on some of our sets and we are looking for a tool that could make that FX for
workshops, shows and other event as well as broadcast!

hope someone can help! my email is pl@...

best regards  
Florent Kermarrec | 15 Sep 19:51 2014
Picon

[M-Labs devel] mor1kx diet

Hi,

by curiosity I've tried to understand why mor1kx uses more logic than LM32 and already discuss of some points with Stefan last week.

To do the comparison, I'm using MiSoC on de0-nano and mixxeo board.

mor1kx and LM32 configurations have to be almost identical, so the attached patch for MiSoC has to be used:
- it disables the store buffer (thanks to the work done by Stefan last week on that).
- it disable burst on Wishbone

One other difference is that LM32 does not support signed division and it's not possible to disable it on mor1kx. By removing the logic specific to the signed part of the division, it saves ~130 LUTs on BaseSoC on Mixxeo.

With the upstream code of mor1kx we have for BaseSoC:
LM32: 2514 regs / 3068 luts
mor1kx: 2761 regs / 3937 luts
--> LM32 beats mor1kx by ~250 regs /  869-130 = ~740 luts.

I've done some others "experiments" on the code to try to reduce this difference, but before doing that I've done some clean up on the code to avoid mixing spaces and tabs
and removed trailing whitespaces, you can merge it... or not :)

The "experiments":
- remove some unneeded resets on some alu registers (divider and multiplier). Since decode_valid_i already invalidates the data, there is no reason to reset the data registers.
- when PIC uses LEVEL interruptions, it's not necessary to registers IRQs.
- to my mind, some simplications can be done in mor1kx_ctrl_cappuccino.v to reduce logic.

which gives me:
mor1kx: 2771 regs / 3828 luts
+10 regs / - 110 luts compared to the upstream code.
timings are also better on Altera and Xilinx.

I have done very limited tests on the code (run MiSoC Bios with SDRAM test on the de0-nano).

With that LM32 still beats mor1kx by ~+250 regs /+ 600 luts... but it was +500 regs/ +1350 luts some days ago :)

Florent 
Attachment (mor1kx_patchs.7z): application/octet-stream, 132 KiB
<div><div dir="ltr">Hi,<div><br></div>
<div>by curiosity I've tried to understand why mor1kx uses more logic than LM32 and already discuss of some points with Stefan last week.</div>
<div><br></div>
<div>To do the comparison, I'm using MiSoC on de0-nano and mixxeo board.<br>
</div>
<div><br></div>
<div>mor1kx and LM32 configurations have to be almost identical, so the attached patch for MiSoC has to be used:</div>
<div>- it disables the store buffer (thanks to the work done by Stefan last week on that).</div>
<div>- it disable burst on Wishbone</div>
<div><br></div>
<div>One other difference is that LM32 does not support signed division and it's not possible to disable it on mor1kx. By removing the logic specific to the signed part of the division, it saves ~130 LUTs on BaseSoC on Mixxeo.</div>
<div><br></div>
<div>With the upstream code of mor1kx we have for BaseSoC:</div>
<div>LM32:&nbsp;2514 regs /&nbsp;3068 luts</div>
<div>mor1kx: 2761 regs / 3937 luts</div>
<div>--&gt; LM32 beats mor1kx by ~250 regs / &nbsp;869-130 = ~740 luts.</div>
<div><br></div>
<div>I've done some others "experiments" on the code to try to reduce this difference, but before doing that I've done some clean up on the code to avoid mixing spaces and tabs</div>
<div>and removed trailing whitespaces, you can merge it... or not :)</div>
<div><br></div>
<div>The "experiments":</div>
<div>- remove some unneeded resets on some alu registers (divider and multiplier). Since decode_valid_i already invalidates the data, there is no reason to reset the data registers.</div>
<div>- when PIC uses LEVEL interruptions, it's not necessary to registers IRQs.</div>
<div>- to my mind, some simplications can be done in&nbsp;mor1kx_ctrl_cappuccino.v to reduce logic.</div>
<div><br></div>
<div>which gives me:</div>
<div>mor1kx: 2771 regs / 3828 luts<br>
</div>
<div>+10 regs / - 110 luts compared to the upstream code.</div>
<div>timings are also better on Altera and Xilinx.</div>
<div><br></div>
<div>I have done very limited tests on the code (run MiSoC Bios with SDRAM test on the de0-nano).</div>
<div><br></div>
<div>With that LM32 still beats mor1kx by ~+250 regs /+ 600 luts... but it was +500 regs/ +1350 luts some days ago :)</div>
<div><br></div>
<div>Florent&nbsp;</div>
</div></div>
Christian Wick | 12 Sep 11:26 2014
Picon

[M-Labs devel] lm32 status JTAG/debug interface

Hello,

what is the status of the lm32 JTAG/debug interface in the current code 
that is available on github?

I know that there is a JTAG tap for the Spartan6, but how can it be used 
for gdb debugging?
I have found some info from Michael Walle on the web who has started to 
implement lm32 support into openocd and who also implemented the 
Spartan6 tap.
So I guess that the plan was/is to use a Xilinx cable to connect to the 
FPGA JTAG port using openocd and then use gdb for debugging, right?

I have also found two discussions about a generic tap controller for the 
lm32:
http://www.mikrocontroller.net/topic/341852#3793537
http://www.mikrocontroller.net/topic/333293#3793536

 From these dicussions I got the info that there are some unknown things 
concerning the JTAG implementation (ER1, ER2 and jtagconn16).
However, since the complete code of the lm32 is available and openocd is 
also open source, the implmentation of the a generic tap controller on 
normal FPGA I/Os pins using openocd should be possible, right?

Best regards,
Christian

Attachment (smime.p7s): application/pkcs7-signature, 5726 bytes
Hello,

what is the status of the lm32 JTAG/debug interface in the current code 
that is available on github?

I know that there is a JTAG tap for the Spartan6, but how can it be used 
for gdb debugging?
I have found some info from Michael Walle on the web who has started to 
implement lm32 support into openocd and who also implemented the 
Spartan6 tap.
So I guess that the plan was/is to use a Xilinx cable to connect to the 
FPGA JTAG port using openocd and then use gdb for debugging, right?

I have also found two discussions about a generic tap controller for the 
lm32:
http://www.mikrocontroller.net/topic/341852#3793537
http://www.mikrocontroller.net/topic/333293#3793536

 From these dicussions I got the info that there are some unknown things 
concerning the JTAG implementation (ER1, ER2 and jtagconn16).
However, since the complete code of the lm32 is available and openocd is 
also open source, the implmentation of the a generic tap controller on 
normal FPGA I/Os pins using openocd should be possible, right?

Best regards,
Christian

Florent Kermarrec | 11 Sep 22:12 2014
Picon

[M-Labs devel] [PATCH] setup.py: fix README filename


Attachment (0001-setup.py-fix-README-filename.patch): application/octet-stream, 952 bytes
<div><div dir="ltr"><br></div></div>
Fabien Marteau | 8 Sep 13:32 2014

[M-Labs devel] [PATCH] README: in markdown for better github presentation

Hi all,

Just little modifications in readme to have a better presentation on
github website. Like my migen fork :
https://github.com/Martoni/migen

Regards,
-- 
Fabien Marteau
FPGA expert & Hardware Engineer
Tel: +33 (0)9 72 29 41 44
Fax: +33 (0)9 72 28 79 26
ARMadeus Systems - A new vision of the embedded world
http://www.armadeus.com

For any confidential message, please encrypt your mail with my
public key :
http://www.martoni.fr/documents/Fabien%20Marteau%20fabien.marteau-d2DlULPkwbNWk0Htik3J/w <at> public.gmane.org%20%280x1A1DA7D8%29%20pub.asc

Hi all,

Just little modifications in readme to have a better presentation on
github website. Like my migen fork :
https://github.com/Martoni/migen

Regards,
--

-- 
Fabien Marteau
FPGA expert & Hardware Engineer
Tel: +33 (0)9 72 29 41 44
Fax: +33 (0)9 72 28 79 26
ARMadeus Systems - A new vision of the embedded world
http://www.armadeus.com

For any confidential message, please encrypt your mail with my
public key :
http://www.martoni.fr/documents/Fabien%20Marteau%20fabien.marteau-d2DlULPkwbNWk0Htik3J/w <at> public.gmane.org%20%280x1A1DA7D8%29%20pub.asc

Robert Jordens | 7 Sep 08:23 2014
Picon

[M-Labs devel] [PATCH] sim/icarus: add vpi directory to module search path

This allows running the iverilog simulations from the migen top directory
without having to install the .vpi anywhere.
---
 migen/sim/icarus.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/migen/sim/icarus.py b/migen/sim/icarus.py
index 36a200a..5eb0396 100644
--- a/migen/sim/icarus.py
+++ b/migen/sim/icarus.py
 <at>  <at>  -26,7 +26,7  <at>  <at>  class Runner:
 		_str2file(self.top_file, c_top)
 		_str2file(self.dut_file, c_dut)
 		subprocess.check_call(["iverilog", "-o", self.vvp_file] + self.options + [self.top_file,
self.dut_file] + self.extra_files)
-		self.process = subprocess.Popen(["vvp", "-mmigensim", self.vvp_file])
+		self.process = subprocess.Popen(["vvp", "-mmigensim", "-Mvpi", self.vvp_file])

 	def close(self):
 		if hasattr(self, "process"):
--

-- 
1.9.1

Robert Jordens | 7 Sep 08:18 2014
Picon

[M-Labs devel] [PATCH 1/2] test_cordic: stop spewing out numbers

---
 migen/test/test_cordic.py | 1 -
 1 file changed, 1 deletion(-)

diff --git a/migen/test/test_cordic.py b/migen/test/test_cordic.py
index 2073a88..7a715aa 100644
--- a/migen/test/test_cordic.py
+++ b/migen/test/test_cordic.py
 <at>  <at>  -47,7 +47,6  <at>  <at>  class CordicCase(SimCase, unittest.TestCase):
 				xo1 = tbp.dut.xo
 				yo1 = tbp.dut.yo
 				zo1 = tbp.dut.zo
-				print((xi, yi, zi), (xo, yo, zo), (xo1, yo1, zo1))
 				self.assertAlmostEqual(xo, xo1, delta=delta)
 				self.assertAlmostEqual(yo, yo1, delta=delta)
 				self.assertAlmostEqual(abs(zo - zo1) % (2*c), 0, delta=deltaz)
--

-- 
1.9.1

Robert Jordens | 7 Sep 08:09 2014
Picon

[M-Labs devel] [PATCH 1/4] examples/dataflow/dma: fix simulation, run it for 100 cycles

---
 examples/dataflow/dma.py | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/examples/dataflow/dma.py b/examples/dataflow/dma.py
index 8bd2728..241d31e 100644
--- a/examples/dataflow/dma.py
+++ b/examples/dataflow/dma.py
 <at>  <at>  -81,11 +81,11  <at>  <at>  class TBWishboneWriter(TBWishbone):

 def test_wb_reader():
 	print("*** Testing Wishbone reader")
-	run_simulation(TBWishboneReader())
+	run_simulation(TBWishboneReader(), 100)

 def test_wb_writer():
 	print("*** Testing Wishbone writer")
-	run_simulation(TBWishboneWriter())
+	run_simulation(TBWishboneWriter(), 100)

 if __name__ == "__main__":
 	test_wb_reader()
--

-- 
1.9.1

Florent Kermarrec | 5 Sep 21:38 2014
Picon

[M-Labs devel] [PATCH] actorlib/spi: add optional external_irq to DMAController


<div><div dir="ltr"><br></div></div>
Robert Jordens | 4 Sep 02:27 2014
Picon

[M-Labs devel] [PATCH 1/7] vivado: mode batch to prevent vivado from opening tcl shell on error

---
 mibuild/xilinx_vivado.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/mibuild/xilinx_vivado.py b/mibuild/xilinx_vivado.py
index 5d18db7..fa472b9 100644
--- a/mibuild/xilinx_vivado.py
+++ b/mibuild/xilinx_vivado.py
 <at>  <at>  -72,7 +72,7  <at>  <at>  def _run_vivado(build_name, vivado_path, source, ver=None):
 	if source:
 		settings = xilinx_common.settings(vivado_path, ver)
 		build_script_contents += "source " + settings + "\n"
-	build_script_contents += "vivado -mode tcl -source " + build_name + ".tcl\n"
+	build_script_contents += "vivado -mode batch -source " + build_name + ".tcl\n"
 	build_script_file = "build_" + build_name + ".sh"
 	tools.write_to_file(build_script_file, build_script_contents, force_unix=True)

--

-- 
1.9.1


Gmane