Thread: [myhdl-list] multiple instantiations
Brought to you by:
jandecaluwe
Menu
▾
▴
myhdl-list
|
From: Henry G. <he...@ca...> - 2015-02-13 13:52:56
|
I think I know the answer to this, but wanted to check. I'm creating lots of instances of the same component (with different signals) - 128 in all. Clearly, this will lead to a pretty unwieldy vhdl file if every one has it's own process block. I understand I could make this neater in raw VHDL (which I can do through MyHDL easily enough) with the generate keyword. Is there a way to do a tight conversion for multiple equivalent instances? Is this one of the targets of MEP 110 (http://dev.myhdl.org/meps/mep-110.html)? Cheers, Henry |
|
From: Edward V. <dev...@sb...> - 2015-02-13 16:18:11
|
Henry, Your problem sounds like what I am working on. In file https://github.com/develone/jpeg-2000-test/blob/master/jpeg2k/parallel_jpeg/jpeg_constants.py I define 8 variables below depending on the bitwidth and the number in the array. W0 = 8 LVL0 = 64 W1 = 8 LVL1 = 64 W2 = 8 LVL2 = 64 W3 = 5 LVL3 = 64 This file generates the Verilog & VHDL https://github.com/develone/jpeg-2000-test/blob/master/jpeg2k/parallel_jpeg/array_jpeg.py 8 64 8 64 8 64 5 64 0 left_s_i <class 'myhdl._Signal._Signal'> sam_s_i <class 'myhdl._Signal._Signal'> right_s_i <class 'myhdl._Signal._Signal'> flgs_s_i <class 'myhdl._Signal._Signal'> 8 64 8 64 8 64 5 64 0 left_s_i <class 'myhdl._Signal._Signal'> sam_s_i <class 'myhdl._Signal._Signal'> right_s_i <class 'myhdl._Signal._Signal'> flgs_s_i <class 'myhdl._Signal._Signal'> My VHDL that is generated has the following entity entity jp_process is port ( res_out_x: out signed (7 downto 0); left_s_i: in unsigned(511 downto 0); sam_s_i: in unsigned(511 downto 0); right_s_i: in unsigned(511 downto 0); flgs_s_i: in unsigned(319 downto 0); noupdate_s: out std_logic; update_s: in std_logic ); end entity jp_process; JP_PROCESS_JPEG_LOGIC: process (update_s, right_s(0), right_s(1), right_s(2), right_s(3), right_s(4), right_s(5), right_s(6), right_s(7), right_s(8), right_s(9), right_s(10), right_s(11), right_s(12), right_s(13), right_s(14), right_s(15), right_s(16), right_s(17), right_s(18), right_s(19), right_s(20), right_s(21), right_s(22), right_s(23), right_s(24), right_s(25), right_s(26), right_s(27), right_s(28), right_s(29), right_s(30), right_s(31), right_s(32), right_s(33), right_s(34), right_s(35), right_s(36), right_s(37), right_s(38), right_s(39), right_s(40), right_s(41), right_s(42), right_s(43), right_s(44), right_s(45), right_s(46), right_s(47), right_s(48), right_s(49), right_s(50), right_s(51), right_s(52), right_s(53), right_s(54), right_s(55), right_s(56), right_s(57), right_s(58), right_s(59), right_s(60), right_s(61), right_s(62), right_s(63), flgs_s(0), flgs_s(1), flgs_s(2), flgs_s(3), flgs_s(4), flgs_s(5), flgs_s(6), flgs_s(7), flgs_s(8), flgs_s(9), flgs_s(10), flgs_s(11), flgs_s(12), flgs_s(13), flgs_s(14), flgs_s(15), flgs_s(16), flgs_s(17), flgs_s(18), flgs_s(19), flgs_s(20), flgs_s(21), flgs_s(22), flgs_s(23), flgs_s(24), flgs_s(25), flgs_s(26), flgs_s(27), flgs_s(28), flgs_s(29), flgs_s(30), flgs_s(31), flgs_s(32), flgs_s(33), flgs_s(34), flgs_s(35), flgs_s(36), flgs_s(37), flgs_s(38), flgs_s(39), flgs_s(40), flgs_s(41), flgs_s(42), flgs_s(43), flgs_s(44), flgs_s(45), flgs_s(46), flgs_s(47), flgs_s(48), flgs_s(49), flgs_s(50), flgs_s(51), flgs_s(52), flgs_s(53), flgs_s(54), flgs_s(55), flgs_s(56), flgs_s(57), flgs_s(58), flgs_s(59), flgs_s(60), flgs_s(61), flgs_s(62), flgs_s(63), sam_s(0), sam_s(1), sam_s(2), sam_s(3), sam_s(4), sam_s(5), sam_s(6), sam_s(7), sam_s(8), sam_s(9), sam_s(10), sam_s(11), sam_s(12), sam_s(13), sam_s(14), sam_s(15), sam_s(16), sam_s(17), sam_s(18), sam_s(19), sam_s(20), sam_s(21), sam_s(22), sam_s(23), sam_s(24), sam_s(25), sam_s(26), sam_s(27), sam_s(28), sam_s(29), sam_s(30), sam_s(31), sam_s(32), sam_s(33), sam_s(34), sam_s(35), sam_s(36), sam_s(37), sam_s(38), sam_s(39), sam_s(40), sam_s(41), sam_s(42), sam_s(43), sam_s(44), sam_s(45), sam_s(46), sam_s(47), sam_s(48), sam_s(49), sam_s(50), sam_s(51), sam_s(52), sam_s(53), sam_s(54), sam_s(55), sam_s(56), sam_s(57), sam_s(58), sam_s(59), sam_s(60), sam_s(61), sam_s(62), sam_s(63), left_s(0), left_s(1), left_s(2), left_s(3), left_s(4), left_s(5), left_s(6), left_s(7), left_s(8), left_s(9), left_s(10), left_s(11), left_s(12), left_s(13), left_s(14), left_s(15), left_s(16), left_s(17), left_s(18), left_s(19), left_s(20), left_s(21), left_s(22), left_s(23), left_s(24), left_s(25), left_s(26), left_s(27), left_s(28), left_s(29), left_s(30), left_s(31), left_s(32), left_s(33), left_s(34), left_s(35), left_s(36), left_s(37), left_s(38), left_s(39), left_s(40), left_s(41), left_s(42), left_s(43), left_s(44), left_s(45), left_s(46), left_s(47), left_s(48), left_s(49), left_s(50), left_s(51), left_s(52), left_s(53), left_s(54), left_s(55), left_s(56), left_s(57), left_s(58), left_s(59), left_s(60), left_s(61), left_s(62), left_s(63)) is begin if bool(update_s) then noupdate_s <= '0'; for i in 0 to LVL0-1 loop if (flgs_s(i) = 7) then res_out_x <= signed(sam_s(i) - (shift_right(left_s(i), 1) + shift_right(right_s(i), 1))); elsif (flgs_s(i) = 5) then res_out_x <= signed(sam_s(i) + (shift_right(left_s(i), 1) + shift_right(right_s(i), 1))); elsif (flgs_s(i) = 6) then res_out_x <= signed(sam_s(i) + shift_right((left_s(i) + (right_s(i) + 2)), 2)); elsif (flgs_s(i) = 4) then res_out_x <= signed(sam_s(i) - shift_right((left_s(i) + (right_s(i) + 2)), 2)); end if; end loop; else noupdate_s <= '1'; end if; end process JP_PROCESS_JPEG_LOGIC; I would like arrays that are larger but now the entity signals become quite large. 8 256 8 256 8 256 5 256 0 left_s_i <class 'myhdl._Signal._Signal'> sam_s_i <class 'myhdl._Signal._Signal'> right_s_i <class 'myhdl._Signal._Signal'> flgs_s_i <class 'myhdl._Signal._Signal'> 8 256 8 256 8 256 5 256 0 left_s_i <class 'myhdl._Signal._Signal'> sam_s_i <class 'myhdl._Signal._Signal'> right_s_i <class 'myhdl._Signal._Signal'> flgs_s_i <class 'myhdl._Signal._Signal'> entity jp_process is port ( res_out_x: out signed (7 downto 0); left_s_i: in unsigned(2047 downto 0); sam_s_i: in unsigned(2047 downto 0); right_s_i: in unsigned(2047 downto 0); flgs_s_i: in unsigned(1279 downto 0); noupdate_s: out std_logic; update_s: in std_logic ); end entity jp_process; Also working on a test bench https://github.com/develone/jpeg-2000-test/blob/master/jpeg2k/parallel_jpeg/test_bench_array_jpeg.py I have been told it might be difficult to work with signals that big. Let me know if this works for you. Regards, Edward Vidal Jr. e-mail dev...@sb... 915-595-1613 On Friday, February 13, 2015 5:53 AM, Henry Gomersall <he...@ca...> wrote: I think I know the answer to this, but wanted to check. I'm creating lots of instances of the same component (with different signals) - 128 in all. Clearly, this will lead to a pretty unwieldy vhdl file if every one has it's own process block. I understand I could make this neater in raw VHDL (which I can do through MyHDL easily enough) with the generate keyword. Is there a way to do a tight conversion for multiple equivalent instances? Is this one of the targets of MEP 110 (http://dev.myhdl.org/meps/mep-110.html)? Cheers, Henry ------------------------------------------------------------------------------ Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ _______________________________________________ myhdl-list mailing list myh...@li... https://lists.sourceforge.net/lists/listinfo/myhdl-list |
|
From: Henry G. <he...@ca...> - 2015-02-13 16:32:06
|
On 13/02/15 16:05, Edward Vidal wrote: > Henry, > Your problem sounds like what I am working on. > <snip> As I understand it, you're doing it by lumping your parallel logic into one block? Or perhaps I've missed something? The problem with this is it breaks a given serial pipeline. My algorithm is embarrassingly parallel, but each parallel stream is not particularly simple. In fact, it gets worse because each serial pipeline is re-purposed in several different ways at run time - essentially I'm wrapping DSP units with lots of data marshalling and shuffling. I really want the serial unit to be as sane as possible, and I'm happy to accept any kind of VHDL to give me that. Cheers, Henry |
|
From: Edward V. <dev...@sb...> - 2015-02-13 16:57:55
|
Henry,
Do you have and example of your code?
Regards
Edward Vidal Jr.
e-mail dev...@sb...
915-595-1613
On Friday, February 13, 2015 8:31 AM, Henry Gomersall <he...@ca...> wrote:
On 13/02/15 16:05, Edward Vidal wrote:
Henry,
>Your problem sounds like what I am working on.
>
>
<snip>
As I understand it, you're doing it by lumping your parallel logic
into one block? Or perhaps I've missed something?
The problem with this is it breaks a given serial pipeline. My
algorithm is embarrassingly parallel, but each parallel stream is
not particularly simple. In fact, it gets worse because each serial
pipeline is re-purposed in several different ways at run time -
essentially I'm wrapping DSP units with lots of data marshalling and
shuffling. I really want the serial unit to be as sane as possible,
and I'm happy to accept any kind of VHDL to give me that.
Cheers,
Henry
------------------------------------------------------------------------------
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/
_______________________________________________
myhdl-list mailing list
myh...@li...
https://lists.sourceforge.net/lists/listinfo/myhdl-list |
|
From: Henry G. <he...@ca...> - 2015-02-13 17:03:33
|
On 13/02/15 16:51, Edward Vidal wrote: > Do you have and example of your code? Not yet! :) (apologies!) |
|
From: Henry G. <he...@ca...> - 2015-02-13 18:42:40
|
On 13/02/15 16:51, Edward Vidal wrote: > Henry, > Do you have and example of your code? Here's an example: https://gist.github.com/hgomersall/9b061b2b92ddc0775789 When converting that, one gets two processes for each TrivialTest. Cheers, Henry |
|
From: Christopher F. <chr...@gm...> - 2015-02-13 19:28:40
|
On 2/13/2015 7:52 AM, Henry Gomersall wrote: > I think I know the answer to this, but wanted to check. > > I'm creating lots of instances of the same component (with different > signals) - 128 in all. Clearly, this will lead to a pretty unwieldy vhdl > file if every one has it's own process block. > > I understand I could make this neater in raw VHDL (which I can do > through MyHDL easily enough) with the generate keyword. > > Is there a way to do a tight conversion for multiple equivalent > instances? Is this one of the targets of MEP 110 > (http://dev.myhdl.org/meps/mep-110.html)? The design is flattened and so each instance will show up as a process in the generated file. And yes, if this was perceived as an issue MEP 110 would address it, MEP 110 could be used to allow one module to be instantiated many times in the generated V* (IIRC MEP 110 is still in draft/proposal it hasn't been accepted?). What is the down side of the flattening? Regards, Chris |
|
From: Henry G. <he...@ca...> - 2015-02-13 19:30:22
|
On 13/02/15 19:28, Christopher Felton wrote: > On 2/13/2015 7:52 AM, Henry Gomersall wrote: >> >I think I know the answer to this, but wanted to check. >> > >> >I'm creating lots of instances of the same component (with different >> >signals) - 128 in all. Clearly, this will lead to a pretty unwieldy vhdl >> >file if every one has it's own process block. >> > >> >I understand I could make this neater in raw VHDL (which I can do >> >through MyHDL easily enough) with the generate keyword. >> > >> >Is there a way to do a tight conversion for multiple equivalent >> >instances? Is this one of the targets of MEP 110 >> >(http://dev.myhdl.org/meps/mep-110.html)? > The design is flattened and so each instance will show up > as a process in the generated file. And yes, if this was > perceived as an issue MEP 110 would address it, MEP 110 > could be used to allow one module to be instantiated many > times in the generated V* (IIRC MEP 110 is still in > draft/proposal it hasn't been accepted?). > > What is the down side of the flattening? Just a massive unwieldy V* file. No other reason. :) Henry |
|
From: Josy B. <jos...@gm...> - 2015-02-15 10:36:28
|
Edward Vidal <develone <at> sbcglobal.net> writes: <snip> > jp_process;JP_PROCESS_JPEG_LOGIC: process (update_s, right_s(0), right_s(1), ..., right_s(63), flgs_s(0), flgs_s(1), ..., flgs_s(63), sam_s(0), sam_s(1), ... , sam_s(63), left_s(0), left_s(1), ... , left_s(63)) is >begin ><snip> I had noticed this behaviour before, and it will generate a warning (at least in the Sigasi VHDL editor). I added this to my MyHDL code in _toVHDL.py: def compressSensitivityList(senslist): ''' reduce spelled out list items like [**name**(0), **name**(1), ..., **name**(n)] to just **name**''' r = [] for item in senslist: name = item._name.split('(',1)[0] if not name in r: r.append( name ) # note that the list now contains names and not Signals, but we are interested in the strings ... return r class _ConvertAlwaysCombVisitor(_ConvertVisitor): def __init__(self, tree, blockBuf, funcBuf): _ConvertVisitor.__init__(self, tree, blockBuf) self.funcBuf = funcBuf def visit_FunctionDef(self, node): self.writeDoc(node) senslist = **compressSensitivityList**( self.tree.senslist ) . . . Your list should now be a short as: jp_process;JP_PROCESS_JPEG_LOGIC: process (update_s, right_s, flgs_s, sam_s, left_s) is Regards, Josy |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X