myhdl-list Mailing List for MyHDL (Page 10)
Brought to you by:
jandecaluwe
You can subscribe to this list here.
2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(14) |
Nov
(4) |
Dec
|
---|---|---|---|---|---|---|---|---|---|---|---|---|
2004 |
Jan
(1) |
Feb
(10) |
Mar
(19) |
Apr
(14) |
May
(1) |
Jun
(4) |
Jul
(10) |
Aug
|
Sep
(2) |
Oct
(7) |
Nov
(17) |
Dec
(12) |
2005 |
Jan
(6) |
Feb
(10) |
Mar
(17) |
Apr
(10) |
May
(9) |
Jun
(5) |
Jul
(26) |
Aug
(34) |
Sep
(10) |
Oct
(38) |
Nov
(71) |
Dec
(74) |
2006 |
Jan
(20) |
Feb
(20) |
Mar
(7) |
Apr
(2) |
May
(13) |
Jun
|
Jul
|
Aug
(4) |
Sep
(37) |
Oct
(43) |
Nov
(30) |
Dec
(33) |
2007 |
Jan
(3) |
Feb
|
Mar
|
Apr
|
May
(30) |
Jun
(9) |
Jul
(1) |
Aug
|
Sep
(8) |
Oct
(13) |
Nov
|
Dec
(4) |
2008 |
Jan
(13) |
Feb
(46) |
Mar
(25) |
Apr
(7) |
May
(20) |
Jun
(73) |
Jul
(38) |
Aug
(47) |
Sep
(24) |
Oct
(18) |
Nov
(9) |
Dec
(36) |
2009 |
Jan
(31) |
Feb
(24) |
Mar
(73) |
Apr
(13) |
May
(47) |
Jun
(28) |
Jul
(36) |
Aug
(2) |
Sep
(5) |
Oct
(8) |
Nov
(16) |
Dec
(29) |
2010 |
Jan
(34) |
Feb
(18) |
Mar
(18) |
Apr
(5) |
May
|
Jun
(24) |
Jul
(53) |
Aug
(3) |
Sep
(18) |
Oct
(33) |
Nov
(19) |
Dec
(15) |
2011 |
Jan
(9) |
Feb
(4) |
Mar
(39) |
Apr
(213) |
May
(86) |
Jun
(46) |
Jul
(22) |
Aug
(11) |
Sep
(78) |
Oct
(59) |
Nov
(38) |
Dec
(24) |
2012 |
Jan
(9) |
Feb
(22) |
Mar
(89) |
Apr
(55) |
May
(222) |
Jun
(86) |
Jul
(57) |
Aug
(32) |
Sep
(49) |
Oct
(69) |
Nov
(12) |
Dec
(35) |
2013 |
Jan
(67) |
Feb
(39) |
Mar
(18) |
Apr
(42) |
May
(79) |
Jun
(1) |
Jul
(19) |
Aug
(18) |
Sep
(54) |
Oct
(79) |
Nov
(9) |
Dec
(26) |
2014 |
Jan
(30) |
Feb
(44) |
Mar
(26) |
Apr
(11) |
May
(39) |
Jun
(1) |
Jul
(89) |
Aug
(15) |
Sep
(7) |
Oct
(6) |
Nov
(20) |
Dec
(27) |
2015 |
Jan
(107) |
Feb
(106) |
Mar
(130) |
Apr
(90) |
May
(147) |
Jun
(28) |
Jul
(53) |
Aug
(16) |
Sep
(23) |
Oct
(7) |
Nov
|
Dec
(16) |
2016 |
Jan
(86) |
Feb
(41) |
Mar
(38) |
Apr
(31) |
May
(37) |
Jun
(11) |
Jul
(1) |
Aug
(1) |
Sep
(3) |
Oct
(1) |
Nov
(5) |
Dec
(3) |
2017 |
Jan
|
Feb
(4) |
Mar
(2) |
Apr
(2) |
May
|
Jun
(3) |
Jul
(2) |
Aug
(2) |
Sep
(1) |
Oct
(2) |
Nov
(1) |
Dec
(1) |
2018 |
Jan
(1) |
Feb
(1) |
Mar
(7) |
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2019 |
Jan
(1) |
Feb
|
Mar
(2) |
Apr
(1) |
May
(1) |
Jun
(2) |
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
(3) |
Dec
|
2020 |
Jan
(1) |
Feb
(2) |
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
(1) |
Aug
(1) |
Sep
(1) |
Oct
|
Nov
|
Dec
(3) |
2021 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
(2) |
Aug
|
Sep
|
Oct
|
Nov
(12) |
Dec
(11) |
2022 |
Jan
(7) |
Feb
(2) |
Mar
(1) |
Apr
|
May
|
Jun
(1) |
Jul
(3) |
Aug
(2) |
Sep
(1) |
Oct
|
Nov
|
Dec
(1) |
2023 |
Jan
|
Feb
(1) |
Mar
(1) |
Apr
(3) |
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
(1) |
2024 |
Jan
(1) |
Feb
(2) |
Mar
(4) |
Apr
(2) |
May
(2) |
Jun
(1) |
Jul
|
Aug
(1) |
Sep
(1) |
Oct
|
Nov
|
Dec
(2) |
2025 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Mr C C. <ch...@be...> - 2016-02-26 16:19:16
|
it will simulate without error, unsurprisingly the waveform doesn't look to be doing anything (even if I change the clock down counter) 12mhz being a little fast to see things changing! but yeah if it simulates and passes through MyHDL but isn't valid verilog then there is a potential bug (at very least in MyHDL's error checking) - even if I'm using MyHDL wrong ;) ! alas I'm going to need someone's help to isolate the issue before it could even be reported as a bug... On 26/02/16 13:25, Christopher Felton wrote: > On 2/26/16 4:36 AM, Mr C Camacho wrote: >> If (probably by using MyHDL incorrectly) yosys reports a syntax >> error with generated verilog, is this a bug with MyHDL (shouldn't >> MyHDL be reporting my idiocy) > If your testbench passes and the converted Verilog > fails then it is something worth looking at to see > if a bug exists. Your best bet to getting working > converted V* is to test the MyHDL code. > >> being as I have no idea what I'm doing or what the error is, I'd >> struggle to reproduce it in a minimal case, but it is just a >> Makefile and a couple of python scripts... >> >> this verilog >> >> 0 <= 1'b0; > You might have forgotten the ".next" in an assignment. > > Regards, > Chris > > > ------------------------------------------------------------------------------ > Site24x7 APM Insight: Get Deep Visibility into Application Performance > APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month > Monitor end-to-end web transactions and take corrective actions now > Troubleshoot faster and improve end-user experience. Signup Now! > http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140 > _______________________________________________ > myhdl-list mailing list > myh...@li... > https://lists.sourceforge.net/lists/listinfo/myhdl-list |
From: Christopher F. <chr...@gm...> - 2016-02-26 13:26:13
|
On 2/26/16 4:36 AM, Mr C Camacho wrote: > If (probably by using MyHDL incorrectly) yosys reports a syntax > error with generated verilog, is this a bug with MyHDL (shouldn't > MyHDL be reporting my idiocy) If your testbench passes and the converted Verilog fails then it is something worth looking at to see if a bug exists. Your best bet to getting working converted V* is to test the MyHDL code. > > being as I have no idea what I'm doing or what the error is, I'd > struggle to reproduce it in a minimal case, but it is just a > Makefile and a couple of python scripts... > > this verilog > > 0 <= 1'b0; You might have forgotten the ".next" in an assignment. Regards, Chris |
From: Mr C C. <ch...@be...> - 2016-02-26 10:36:53
|
If (probably by using MyHDL incorrectly) yosys reports a syntax error with generated verilog, is this a bug with MyHDL (shouldn't MyHDL be reporting my idiocy) being as I have no idea what I'm doing or what the error is, I'd struggle to reproduce it in a minimal case, but it is just a Makefile and a couple of python scripts... this verilog 0 <= 1'b0; is where the error is happening but I'm doing something dumb obviously because earlier input [7:0] LEDS; I'm attempting (probably incorrectly) to pass a top level output to a module where its manipulated although the scripts are small I've not attached them as this usually triggers netiquette SJW's for some reason and I just can't be bothered..... |
From: Edward V. <dev...@sb...> - 2016-02-25 23:54:18
|
Hi All I too have been working with C. Felton and Dave Vandenbout https://hackaday.io/project/7982-cat-board who developed the CAT-Board for the Raspberry Pi. Some of the things work okay with the yosys-tools. My RPi2B with CatBoard are running in my home. http://99.184.183.104/video.webm The Catboard was program with the yosys tools. For my catboard_blinky_host I had to use iCECube2 from Lattice. This use C. Felton rhea and myhdl to generate the verilog code. https://github.com/develone/jpeg-2000-test/blob/master/pc_fast_blinker_jpeg/input_examples/catboard_blinky_host.py One of the things that I find really great is myhdl simulation. python test_catboard_blinky_host.py --trace & python test_catboard_blinky_host.py --build wc iceriver/catboard.v 1221 3131 35222 iceriver/catboard.v If you have any question let me know. Regards, Edward Vidal Jr. e-mail dev...@sb... 915-595-1613 On Thursday, February 25, 2016 3:46 PM, Mr C Camacho <ch...@be...> wrote: yeah the icestorm tools are sweet, programming just the cram is a nice option and blisteringly fast :) the combination of MyHDL and icestorm is nice... mind I have noticed some oddities for example comparing list/tuple intbv elements with a intbv is still defeating me... I guess I'm still trying to get my head round the subtleties ! On 25/02/16 22:39, Jan Coombs wrote: > On Thu, 25 Feb 2016 21:03:22 +0000 > Mr C Camacho <ch...@be...> wrote: > >> Don't suppose you've got a saner example of including a >> verilog module within a MyHDL do you? it's either way less >> complex than it looks or I'm missing something here! > I have wrapped Lattice library components to make them simulate > or export for synthesis. > > The smallest wrapper I have is for a Lattice XO2 internal osc > - 47 lines. > > Have also an iCE40 SB_RAM256X16.py with initialization, which I > have used. > > I also started wrapping everything from the iCE40 primitive > library, thinking I might ignore the synthesis tool and do it all > in MyHDL, but most of this is untested. > > Have you noticed that the icestorm tools can program an iCE40 > part in just 2s? > > Let me know if you'd like anything emailed. > > Jan Coombs. ------------------------------------------------------------------------------ Site24x7 APM Insight: Get Deep Visibility into Application Performance APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month Monitor end-to-end web transactions and take corrective actions now Troubleshoot faster and improve end-user experience. Signup Now! http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140 _______________________________________________ myhdl-list mailing list myh...@li... https://lists.sourceforge.net/lists/listinfo/myhdl-list |
From: Mr C C. <ch...@be...> - 2016-02-25 22:46:41
|
yeah the icestorm tools are sweet, programming just the cram is a nice option and blisteringly fast :) the combination of MyHDL and icestorm is nice... mind I have noticed some oddities for example comparing list/tuple intbv elements with a intbv is still defeating me... I guess I'm still trying to get my head round the subtleties ! On 25/02/16 22:39, Jan Coombs wrote: > On Thu, 25 Feb 2016 21:03:22 +0000 > Mr C Camacho <ch...@be...> wrote: > >> Don't suppose you've got a saner example of including a >> verilog module within a MyHDL do you? it's either way less >> complex than it looks or I'm missing something here! > I have wrapped Lattice library components to make them simulate > or export for synthesis. > > The smallest wrapper I have is for a Lattice XO2 internal osc > - 47 lines. > > Have also an iCE40 SB_RAM256X16.py with initialization, which I > have used. > > I also started wrapping everything from the iCE40 primitive > library, thinking I might ignore the synthesis tool and do it all > in MyHDL, but most of this is untested. > > Have you noticed that the icestorm tools can program an iCE40 > part in just 2s? > > Let me know if you'd like anything emailed. > > Jan Coombs. |
From: Jan C. <jen...@mu...> - 2016-02-25 22:39:37
|
On Thu, 25 Feb 2016 21:03:22 +0000 Mr C Camacho <ch...@be...> wrote: > Don't suppose you've got a saner example of including a > verilog module within a MyHDL do you? it's either way less > complex than it looks or I'm missing something here! I have wrapped Lattice library components to make them simulate or export for synthesis. The smallest wrapper I have is for a Lattice XO2 internal osc - 47 lines. Have also an iCE40 SB_RAM256X16.py with initialization, which I have used. I also started wrapping everything from the iCE40 primitive library, thinking I might ignore the synthesis tool and do it all in MyHDL, but most of this is untested. Have you noticed that the icestorm tools can program an iCE40 part in just 2s? Let me know if you'd like anything emailed. Jan Coombs. -- email valid at present... |
From: Mr C C. <ch...@be...> - 2016-02-25 21:03:32
|
>This isn't a minimilistic example or an iCE PLL example but it is an example of wrapping a Xilinx >MMCM https://github.com/cfelton/rhea/blob/master/rhea/vendor/xilinx/_device_clock_mgmt.py >Regards, Chris lol - yeah ya not kidding it's going to take me this side of next month just to figure out how to get that working!!! Don't suppose you've got a saner example of including a verilog module within a MyHDL do you? it's either way less complex than it looks or I'm missing something here! thx Chris |
From: Christopher F. <chr...@gm...> - 2016-02-25 20:42:59
|
>> >> if that isn't possible, could someone give me an example wrapped in a >> custom verilog clause? > > This isn't a minimilistic example or an iCE PLL example > but it is an example of wrapping a Xilinx MMCM > https://github.com/cfelton/rhea/blob/master/rhea/vendor/xilinx/_device_clock_mgmt.py > Here is an example wrapping an iCE40 (?) `SB_IO`: https://github.com/xesscorp/CAT-Board/blob/master/tests/ice40_primitives.py Regards, Chris |
From: Christopher F. <chr...@gm...> - 2016-02-25 20:36:41
|
> > One thing I can't seem to find any info about - what do I do with the > icepll output > > here's a verilog example > https://github.com/SubProto/icestick-vga-test/blob/master/vga.v > > how do I replicate the SB_PLL40_CORE and instance it in python (MyHDL) > > if that isn't possible, could someone give me an example wrapped in a > custom verilog clause? This isn't a minimilistic example or an iCE PLL example but it is an example of wrapping a Xilinx MMCM https://github.com/cfelton/rhea/blob/master/rhea/vendor/xilinx/_device_clock_mgmt.py Regards, Chris > > on the 8k board how do you instance both PLL's - do you have to do > anything specific if you want to use both sources and also feed one into > the other? No you shouldn't have to do anything special, just instance the two PLLs and connect as you want. Regards, Chris |
From: Mr C C. <ch...@be...> - 2016-02-25 20:18:42
|
I'm genuinely pleasantly surprised by how much difference MyHDL make to the ease of use and general accessibility of FPGA's (you never know manufacturers might be so impressed they send you all their internal docs ;) - okay you can stop laughing now - but wouldn't they sell more chips? ) My previous experience has been with some 6GB monstrosity of a tool chain and well... it just wasn't fun, using MyHDL and Icestorm is a very much more pleasant and productive experience Thanks! One thing I can't seem to find any info about - what do I do with the icepll output here's a verilog example https://github.com/SubProto/icestick-vga-test/blob/master/vga.v how do I replicate the SB_PLL40_CORE and instance it in python (MyHDL) if that isn't possible, could someone give me an example wrapped in a custom verilog clause? on the 8k board how do you instance both PLL's - do you have to do anything specific if you want to use both sources and also feed one into the other? Once again thanks for MyHDL, fantastic work! C |
From: Christopher F. <chr...@gm...> - 2016-02-25 17:11:49
|
On 2/25/2016 11:00 AM, Ben Reynwar wrote: > That makes sense. So when I'm experimenting with things like this, > I can write a generic modules using interfaces, but when testing it, > wrap it with an explicit module so that I don't have any interfaces > in my top-level. Yes, that is a recipe for success :) I will do things like the following to make the explicit ports in the top-levels easier to manage def my_core_top( # somewhat painful explicitly listing the ports # ... ) portmap = dict(clock=Signal(bool(0)) portmap.update(axi4lite_portmap) my_core_top.portmap = portmap In my testbenches and conversion scripts I don't need to type out all those ports again portmap = my_core_top.portmap clock = portmap['clock'] axi = AXI4LiteInterface(portmap) tbdut = my_core_top(**portmap) To me this makes sense because a top-level maps to an explicit static hardware device, having tools to map the explicit portmap to the generic interfaces is a good approach, in my opinion. Regards, Chris |
From: Ben R. <be...@re...> - 2016-02-25 17:00:50
|
That makes sense. So when I'm experimenting with things like this, I can write a generic modules using interfaces, but when testing it, wrap it with an explicit module so that I don't have any interfaces in my top-level. Thanks again for your help. Cheers, Ben On Thu, Feb 25, 2016 at 9:53 AM, Christopher Felton <chr...@gm...> wrote: > On 2/25/2016 10:30 AM, Ben Reynwar wrote: > > Thanks. I have faint memories of running into something similar last > time > > I played with MyHDL about a year ago, so it's possible it was me running > > into it last time! Is the use of interfaces still fairly uncommon in > > MyHDL, or are they pretty mainstream now? > > > > I use interfaces all the time, to me it is critical. > But I do not use top-level interfaces, I only use > them in the design. I typically write a wrapper > for MyHDL modules that I use as submodules in a > larger mixed HDL design. > > Interfaces in the design are mainstream! There are > issues with interface top-level conversion, at first > we were not going to include top-level conversion > (kinda like list-of-signals). One of the reasons > things might not of changed in this area is because > of the MEP114 addition (@myhdl.module), meaning that > this issue has been (will be) put on the back burner > until MEP114 is merged into master. > > Regards, > Chris > > > > > ------------------------------------------------------------------------------ > Site24x7 APM Insight: Get Deep Visibility into Application Performance > APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month > Monitor end-to-end web transactions and take corrective actions now > Troubleshoot faster and improve end-user experience. Signup Now! > http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140 > _______________________________________________ > myhdl-list mailing list > myh...@li... > https://lists.sourceforge.net/lists/listinfo/myhdl-list > |
From: Christopher F. <chr...@gm...> - 2016-02-25 16:54:01
|
On 2/25/2016 10:30 AM, Ben Reynwar wrote: > Thanks. I have faint memories of running into something similar last time > I played with MyHDL about a year ago, so it's possible it was me running > into it last time! Is the use of interfaces still fairly uncommon in > MyHDL, or are they pretty mainstream now? > I use interfaces all the time, to me it is critical. But I do not use top-level interfaces, I only use them in the design. I typically write a wrapper for MyHDL modules that I use as submodules in a larger mixed HDL design. Interfaces in the design are mainstream! There are issues with interface top-level conversion, at first we were not going to include top-level conversion (kinda like list-of-signals). One of the reasons things might not of changed in this area is because of the MEP114 addition (@myhdl.module), meaning that this issue has been (will be) put on the back burner until MEP114 is merged into master. Regards, Chris |
From: Ben R. <be...@re...> - 2016-02-25 16:30:58
|
Thanks. I have faint memories of running into something similar last time I played with MyHDL about a year ago, so it's possible it was me running into it last time! Is the use of interfaces still fairly uncommon in MyHDL, or are they pretty mainstream now? On Thu, Feb 25, 2016 at 8:14 AM, Christopher Felton <chr...@gm...> wrote: > On 2/25/2016 8:34 AM, Ben Reynwar wrote: > > Thanks for the help Chris. I've updated the code so that I have 3 input > > signals (i_a, i_b, i_c) and 2 output signals (o_b, o_c). > > > > The name mangling converts both i_b and i_c to i, and both o_b and o_c to > > o. How should I get around this issue? > > > > This seems to be a bug, I did an explicit version [1] > and and got similar results: > > def top_level_assign(intf_in, intf_out): > m1 = assign(intf_in.b, intf_out.b) > m2 = assign(intf_in.c, intf_out.c) > return m1, m2 > > module top_level_assign ( > b, > b, > a, > a, > intf_in_a > ); > > There might be an issue created for this already, I > need to check (vaguely recall discussing something > similar in the past). If not an issue should be > created. > > Regards, > Chris > > [1] https://gist.github.com/cfelton/81c680347dc6b2d5a458 > > > > > > ------------------------------------------------------------------------------ > Site24x7 APM Insight: Get Deep Visibility into Application Performance > APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month > Monitor end-to-end web transactions and take corrective actions now > Troubleshoot faster and improve end-user experience. Signup Now! > http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140 > _______________________________________________ > myhdl-list mailing list > myh...@li... > https://lists.sourceforge.net/lists/listinfo/myhdl-list > |
From: Samuele D. <sm...@gm...> - 2016-02-25 15:15:39
|
I am sorry.. Previous code is wrong. Il 25/Feb/2016 16:05, "Samuele Disegna" <sm...@gm...> ha scritto: > What about this? > > multout = [Signal(intbv(0, min=de.min*coeff, max=de.max*coeff)) for coeff > in coeffs] > > resized_multout = [Signal(intbv(0, min=de.min*coeffmax, > max=de.max*coeffmax)) for coeff in coeffs] > > for i in range(len(coeffs)): > @always_comb > def res(): > resized_multout[i].next = multout[i] > > @always_comb > def outdat(): > totsum = 0 > for i in range(len(coeffs)): > totsum += resized_multout[i] > qe.data.next = totsum > > Samuele > Il 25/Feb/2016 15:38, "David Belohrad" <da...@be...> ha scritto: > >> Hi all, >> >> that is indeed exactly what I want to do. I do not want instantiate a >> memory like iface, but rather bunch of individual signals, which will be >> properly linked. >> >> using this construct: >> multout = [Signal(intbv(0, min=de.min*coeff, max=de.max*coeff)) for coeff >> in coeffs] >> >> outside of the yield functions works exactly as expected, i.e. it >> generates tons of signals. Problem is, that I use multout as follows: >> >> @always_comb >> def outdat(): >> totsum = 0 >> for i in range(len(coeffs)): >> totsum += multout[i] >> qe.data.next = totsum >> >> and when multout is inside any decorated block it tries to instantiate >> memory-like array (as properly stated in docs), which i'd like to avoid and >> instead generate 'on-fly' totsum = resize(multout[0], >> totsum'length)+resize(multout[1], totsum'length)+.... >> >> which would permit me to take control over length of multout (which is an >> output of multiplier, hence I'd like to use minimum amount of bits to >> implement it to control fpga resources)... >> >> >> >> >> >> >> Christopher Felton <chr...@gm...> writes: >> >> >> this does not seem to be convertible, as the signals in the array >> >> have different lengths >> >> >> >> multout = [Signal(intbv(0, min=de.min*coeff, max=de.max*coeff)) for >> >> coeff in coeffs] >> > >> > You can't do this, in hardware if they are all different >> > types they would need to be mapped to some non-homogeneous >> > structure (i.e. not memory). >> > >> > What I would do if first find the min and max in your >> > coefficients and create the coefficient array >> > (list-of-signals) from the overall collection's min and >> > max. Then you have a structure that can be mapped to >> > to a memory if needed. >> > >> > If that is not desired, you don't have much choice but >> > to individually select the different size `coeff`. Note, >> > if you use the ROM [1] structure (tuple-of-ints) it will >> > use the minimal hardware you desire. >> > >> > Regards, >> > Chris >> > >> > >> > [1] >> > >> http://docs.myhdl.org/en/stable/manual/conversion_examples.html#rom-inference >> > >> > >> > >> ------------------------------------------------------------------------------ >> > Site24x7 APM Insight: Get Deep Visibility into Application Performance >> > APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month >> > Monitor end-to-end web transactions and take corrective actions now >> > Troubleshoot faster and improve end-user experience. Signup Now! >> > http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140 >> > _______________________________________________ >> > myhdl-list mailing list >> > myh...@li... >> > https://lists.sourceforge.net/lists/listinfo/myhdl-list >> >> >> ------------------------------------------------------------------------------ >> Site24x7 APM Insight: Get Deep Visibility into Application Performance >> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month >> Monitor end-to-end web transactions and take corrective actions now >> Troubleshoot faster and improve end-user experience. Signup Now! >> http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140 >> _______________________________________________ >> myhdl-list mailing list >> myh...@li... >> https://lists.sourceforge.net/lists/listinfo/myhdl-list >> > |
From: Christopher F. <chr...@gm...> - 2016-02-25 15:15:07
|
On 2/25/2016 8:34 AM, Ben Reynwar wrote: > Thanks for the help Chris. I've updated the code so that I have 3 input > signals (i_a, i_b, i_c) and 2 output signals (o_b, o_c). > > The name mangling converts both i_b and i_c to i, and both o_b and o_c to > o. How should I get around this issue? > This seems to be a bug, I did an explicit version [1] and and got similar results: def top_level_assign(intf_in, intf_out): m1 = assign(intf_in.b, intf_out.b) m2 = assign(intf_in.c, intf_out.c) return m1, m2 module top_level_assign ( b, b, a, a, intf_in_a ); There might be an issue created for this already, I need to check (vaguely recall discussing something similar in the past). If not an issue should be created. Regards, Chris [1] https://gist.github.com/cfelton/81c680347dc6b2d5a458 |
From: Samuele D. <sm...@gm...> - 2016-02-25 15:05:51
|
What about this? multout = [Signal(intbv(0, min=de.min*coeff, max=de.max*coeff)) for coeff in coeffs] resized_multout = [Signal(intbv(0, min=de.min*coeffmax, max=de.max*coeffmax)) for coeff in coeffs] for i in range(len(coeffs)): @always_comb def res(): resized_multout[i].next = multout[i] @always_comb def outdat(): totsum = 0 for i in range(len(coeffs)): totsum += resized_multout[i] qe.data.next = totsum Samuele Il 25/Feb/2016 15:38, "David Belohrad" <da...@be...> ha scritto: > Hi all, > > that is indeed exactly what I want to do. I do not want instantiate a > memory like iface, but rather bunch of individual signals, which will be > properly linked. > > using this construct: > multout = [Signal(intbv(0, min=de.min*coeff, max=de.max*coeff)) for coeff > in coeffs] > > outside of the yield functions works exactly as expected, i.e. it > generates tons of signals. Problem is, that I use multout as follows: > > @always_comb > def outdat(): > totsum = 0 > for i in range(len(coeffs)): > totsum += multout[i] > qe.data.next = totsum > > and when multout is inside any decorated block it tries to instantiate > memory-like array (as properly stated in docs), which i'd like to avoid and > instead generate 'on-fly' totsum = resize(multout[0], > totsum'length)+resize(multout[1], totsum'length)+.... > > which would permit me to take control over length of multout (which is an > output of multiplier, hence I'd like to use minimum amount of bits to > implement it to control fpga resources)... > > > > > > > Christopher Felton <chr...@gm...> writes: > > >> this does not seem to be convertible, as the signals in the array > >> have different lengths > >> > >> multout = [Signal(intbv(0, min=de.min*coeff, max=de.max*coeff)) for > >> coeff in coeffs] > > > > You can't do this, in hardware if they are all different > > types they would need to be mapped to some non-homogeneous > > structure (i.e. not memory). > > > > What I would do if first find the min and max in your > > coefficients and create the coefficient array > > (list-of-signals) from the overall collection's min and > > max. Then you have a structure that can be mapped to > > to a memory if needed. > > > > If that is not desired, you don't have much choice but > > to individually select the different size `coeff`. Note, > > if you use the ROM [1] structure (tuple-of-ints) it will > > use the minimal hardware you desire. > > > > Regards, > > Chris > > > > > > [1] > > > http://docs.myhdl.org/en/stable/manual/conversion_examples.html#rom-inference > > > > > > > ------------------------------------------------------------------------------ > > Site24x7 APM Insight: Get Deep Visibility into Application Performance > > APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month > > Monitor end-to-end web transactions and take corrective actions now > > Troubleshoot faster and improve end-user experience. Signup Now! > > http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140 > > _______________________________________________ > > myhdl-list mailing list > > myh...@li... > > https://lists.sourceforge.net/lists/listinfo/myhdl-list > > > ------------------------------------------------------------------------------ > Site24x7 APM Insight: Get Deep Visibility into Application Performance > APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month > Monitor end-to-end web transactions and take corrective actions now > Troubleshoot faster and improve end-user experience. Signup Now! > http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140 > _______________________________________________ > myhdl-list mailing list > myh...@li... > https://lists.sourceforge.net/lists/listinfo/myhdl-list > |
From: David B. <da...@be...> - 2016-02-25 14:38:47
|
Hi all, that is indeed exactly what I want to do. I do not want instantiate a memory like iface, but rather bunch of individual signals, which will be properly linked. using this construct: multout = [Signal(intbv(0, min=de.min*coeff, max=de.max*coeff)) for coeff in coeffs] outside of the yield functions works exactly as expected, i.e. it generates tons of signals. Problem is, that I use multout as follows: @always_comb def outdat(): totsum = 0 for i in range(len(coeffs)): totsum += multout[i] qe.data.next = totsum and when multout is inside any decorated block it tries to instantiate memory-like array (as properly stated in docs), which i'd like to avoid and instead generate 'on-fly' totsum = resize(multout[0], totsum'length)+resize(multout[1], totsum'length)+.... which would permit me to take control over length of multout (which is an output of multiplier, hence I'd like to use minimum amount of bits to implement it to control fpga resources)... Christopher Felton <chr...@gm...> writes: >> this does not seem to be convertible, as the signals in the array >> have different lengths >> >> multout = [Signal(intbv(0, min=de.min*coeff, max=de.max*coeff)) for >> coeff in coeffs] > > You can't do this, in hardware if they are all different > types they would need to be mapped to some non-homogeneous > structure (i.e. not memory). > > What I would do if first find the min and max in your > coefficients and create the coefficient array > (list-of-signals) from the overall collection's min and > max. Then you have a structure that can be mapped to > to a memory if needed. > > If that is not desired, you don't have much choice but > to individually select the different size `coeff`. Note, > if you use the ROM [1] structure (tuple-of-ints) it will > use the minimal hardware you desire. > > Regards, > Chris > > > [1] > http://docs.myhdl.org/en/stable/manual/conversion_examples.html#rom-inference > > > ------------------------------------------------------------------------------ > Site24x7 APM Insight: Get Deep Visibility into Application Performance > APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month > Monitor end-to-end web transactions and take corrective actions now > Troubleshoot faster and improve end-user experience. Signup Now! > http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140 > _______________________________________________ > myhdl-list mailing list > myh...@li... > https://lists.sourceforge.net/lists/listinfo/myhdl-list |
From: Ben R. <be...@re...> - 2016-02-25 14:34:16
|
Thanks for the help Chris. I've updated the code so that I have 3 input signals (i_a, i_b, i_c) and 2 output signals (o_b, o_c). The name mangling converts both i_b and i_c to i, and both o_b and o_c to o. How should I get around this issue? On Thu, Feb 25, 2016 at 6:49 AM, Christopher Felton <chr...@gm...> wrote: > On 2/24/2016 10:00 PM, Ben Reynwar wrote: > > And five minutes after posting I found a bug in my code that > > explained why the simulation wasn't working. I had inputs and > > outputs wrong way round! However, I still am having issues with the > > verilog generation. > > > It looks like it is working, what is the issue you are > having? > > There is a known side-effect when converting top-level > interface ports. When converting the interfaces some > name-mangling occurs, the Python compiler does this > renaming. > > Regards, > Chris > > > > ------------------------------------------------------------------------------ > Site24x7 APM Insight: Get Deep Visibility into Application Performance > APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month > Monitor end-to-end web transactions and take corrective actions now > Troubleshoot faster and improve end-user experience. Signup Now! > http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140 > _______________________________________________ > myhdl-list mailing list > myh...@li... > https://lists.sourceforge.net/lists/listinfo/myhdl-list > |
From: Christopher F. <chr...@gm...> - 2016-02-25 13:49:38
|
On 2/24/2016 10:00 PM, Ben Reynwar wrote: > And five minutes after posting I found a bug in my code that > explained why the simulation wasn't working. I had inputs and > outputs wrong way round! However, I still am having issues with the > verilog generation. It looks like it is working, what is the issue you are having? There is a known side-effect when converting top-level interface ports. When converting the interfaces some name-mangling occurs, the Python compiler does this renaming. Regards, Chris |
From: Christopher F. <chr...@gm...> - 2016-02-25 13:24:35
|
> this does not seem to be convertible, as the signals in the array > have different lengths > > multout = [Signal(intbv(0, min=de.min*coeff, max=de.max*coeff)) for > coeff in coeffs] You can't do this, in hardware if they are all different types they would need to be mapped to some non-homogeneous structure (i.e. not memory). What I would do if first find the min and max in your coefficients and create the coefficient array (list-of-signals) from the overall collection's min and max. Then you have a structure that can be mapped to to a memory if needed. If that is not desired, you don't have much choice but to individually select the different size `coeff`. Note, if you use the ROM [1] structure (tuple-of-ints) it will use the minimal hardware you desire. Regards, Chris [1] http://docs.myhdl.org/en/stable/manual/conversion_examples.html#rom-inference |
From: Samuele D. <sm...@gm...> - 2016-02-25 12:42:27
|
Hi, I am just a new user of MyHDL. But for what I understand lists of signals must have same type (see hardware oriented types docs). You can use an interface to group different Signals. You will lose the ability to index them. Is it fine? You could try to implement indexing on an interface in MyHDL sources. That would be the proper solution. There are also some bad hacks you can do with python using locals(). What's your purpose? Samuele Il 25/Feb/2016 11:53, "David Belohrad" <da...@be...> ha scritto: > Hi all, > > the problem is following: > > this is convertible, as all the signals in the array have the same length: > > multout = [Signal(intbv(0, min=de.min*min(coeffs), > max=de.max*max(coeffs))) for coeff in coeffs] > > this does not seem to be convertible, as the signals in the array have > different lengths > > multout = [Signal(intbv(0, min=de.min*coeff, max=de.max*coeffs)) for coeff > in coeffs] > > > how to make the second construct behave as a simple list of different > signals rather than an array? The first construct is converted into VHDL as > an array: > > type t_array_multout is array(0 to 4-1) of unsigned(21 downto 0); > signal multout: t_array_multout; > > evidently this cannot be with the second as in order to make the second > one running it has to be exploded to individual items. any way how to > achieve this? > > any hint very appreciated. > > thanks > .d. > > > ------------------------------------------------------------------------------ > Site24x7 APM Insight: Get Deep Visibility into Application Performance > APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month > Monitor end-to-end web transactions and take corrective actions now > Troubleshoot faster and improve end-user experience. Signup Now! > http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140 > _______________________________________________ > myhdl-list mailing list > myh...@li... > https://lists.sourceforge.net/lists/listinfo/myhdl-list > |
From: David B. <da...@be...> - 2016-02-25 10:53:11
|
Hi all, the problem is following: this is convertible, as all the signals in the array have the same length: multout = [Signal(intbv(0, min=de.min*min(coeffs), max=de.max*max(coeffs))) for coeff in coeffs] this does not seem to be convertible, as the signals in the array have different lengths multout = [Signal(intbv(0, min=de.min*coeff, max=de.max*coeffs)) for coeff in coeffs] how to make the second construct behave as a simple list of different signals rather than an array? The first construct is converted into VHDL as an array: type t_array_multout is array(0 to 4-1) of unsigned(21 downto 0); signal multout: t_array_multout; evidently this cannot be with the second as in order to make the second one running it has to be exploded to individual items. any way how to achieve this? any hint very appreciated. thanks .d. |
From: Ben R. <be...@re...> - 2016-02-25 04:19:47
|
Hi all, I'm experimenting with MyHDL and am trying to write a module that connects inputs and outputs based on the signals names. I doing this to get a feel for what MyHDL can and cannot do. The code is at https://gist.github.com/benreynwar/5963c2658883322be7c4 including the generated verilog. The module "Reduces" takes a generic input interface, and a generic output interface. All signals which have the same name in both the input and output interface are connected. Any other signals are ignored. It simulates without complaining but does not give the output I would expect. The outputs remain unchanged. It generates verilog without error, but the generated verilog does not match what I would expect. I expect I'm going about this wrong, since I have little experience with MyHDL. Any pointers would be appreciated. Cheers, Ben |
From: Ben R. <be...@re...> - 2016-02-25 04:00:40
|
And five minutes after posting I found a bug in my code that explained why the simulation wasn't working. I had inputs and outputs wrong way round! However, I still am having issues with the verilog generation. On Wed, Feb 24, 2016 at 8:54 PM, Ben Reynwar <be...@re...> wrote: > Hi all, > > I'm experimenting with MyHDL and am trying to write a module that connects > inputs and outputs based on the signals names. I doing this to get a feel > for what MyHDL can and cannot do. > > The code is at https://gist.github.com/benreynwar/5963c2658883322be7c4 > including the generated verilog. > > The module "Reduces" takes a generic input interface, and a generic output > interface. All signals which have the same name in both the input and > output interface are connected. > Any other signals are ignored. > > It simulates without complaining but does not give the output I would > expect. The outputs remain unchanged. > > It generates verilog without error, but the generated verilog does not > match what I would expect. > > I expect I'm going about this wrong, since I have little experience with > MyHDL. Any pointers would be appreciated. > > Cheers, > Ben > |