On 29 Nov 2013, at 5:39 am, Adrien Prost-Boucle 
<[email protected]> wrote:

> For the little story, the fsm.vhd represents only the FSM entity of a
> much bigger circuit. The initial application is "motion" from the
> CHStone benchmark suite http://www.ertl.jp/chstone/ (Motion vector
> decoding of the MPEG-2).

My guess would have been something along those lines.  I've written very large 
state machines for doing things like international standards conversion (NTSC 
<-> PAL) in a 2D DCT compression system.  In Fortran using bipolar PROMs, this 
in the early '80s.   Use to draw them out on big pieces of paper too.  No where 
near as many states.

> But with an average of 5kB used per bit, like David mentioned,
> it would not be simple duplication, rather creation of 100 copies of these 
> arrays xD

Not just copies.  Also executable code.  The question is how big those 

   something <= (others => '0');

assignments get unfolded for big arrays.

Your included file tb.vhd doesn't seem to have anything to do with fsm.vhd 
(without seeing component top).

I had a terrible time with tb.vhd, starting with the editor I was using 
(TextMate, then TextEdit, OS X apps).  Switched to joe and found out why.

You have some long array 'initialization' lines (these are constants, 
in_vector_nb, and out_vector_nb, and say what does _nb signify anyway? Oh, 
number.) in the test bench.  Line 74 is 2588734 characters long. Line 67 is 
31291 characters long.

You might want to think about formatting this if it's generated VHDL code.  
There isn't a specified line length that must be supported in VHDL.  2.5 MB 
seems a bit excessive.

It's legal to build a line input VHDL analyzer and for things that take command 
line arguments (e.g. filters for highlighting editors) there's three factors 
limiting how long a line can be.  The maximum length of the line (1/4 the stack 
size in later Linuxes, generally smaller in other UNIXes), maximum number of 
arguments and maximum argument size. 

It's common for VHDL analyzers (lexers) to operate out of a memory copy of an 
input file and treat a design file as a single dimensional array, where format 
effectors (in this case new line characters) are simply speed bumps in 
traversing the design description.  An end of line always terminates a lexical 
element (accept a multi-line comment in -2008, and comments aren't generally 
returned lexical tokens).  Operating out of a memory array is not required and 
no 'minimum' maximum line length is specified for operating out of a line 
buffer.  In general you'd expect a tool author to honor line sizes implied for 
line oriented tools.

Mind you I consider gnat's penchant for 80 column lines to be a bit overboard, 
too.  That appears to be for purposes of formal verification, communicating to 
something through dusty decks (punch cards). (Newer gcc ada builds have all the 
gnat warnings turned on by default, like the one for trailing white pace.  
Doesn't hurt except -Werror is turned on too.)

Anyway a VHDL design description is also intended to be read.  I took the first 
Synopsys VHDL Design Compiler class oh so many years ago now.  On the class 
critique I commented to the effect VHDL is a wonderful language for describing 
hardware but no one has any business actually writing it (by hand) in keeping 
with the idea of generating VHDL design descriptions programmatically.  It 
still needs to be readable and more importantly filterable, which can be 
generally line oriented.

Without top_i being bound your test doesn't do anything.  It does analyze 
successfully.  All the textio stuff for monitoring the process is impressive.  
Doesn't get exercised, though.

david_koontz@Macbook: ghdl -a tb.vhd
david_koontz@Macbook: ghdl -r tb
tb.vhd:89:8:warning: component instance "top_i" is not bound
tb.vhd:13:14:warning: (in default configuration of tb(a))
tb.vhd:130:32:@10ns:(report note): INFO Reset
tb.vhd:130:32:@20ns:(report note): INFO Reset
tb.vhd:130:32:@30ns:(report note): INFO Reset
tb.vhd:134:32:@40ns:(report note): INFO Start
tb.vhd:126:32:@500010ns:(report failure): ERROR Too many cycles simulated. 
Stopping simulation.
ghdl:error: report failed
Segmentation fault

Not sure without a good editor what's with the segmentation fault need to 
search for the a report statement likely failing, is that due to a lack of 
top_i? 

Was this the test bench you intended to send?








_______________________________________________
Ghdl-discuss mailing list
[email protected]
https://mail.gna.org/listinfo/ghdl-discuss

Reply via email to