On Nov 30, 2011, at 1:04 AM, Svenn Are Bjerkem wrote: > Hi, > > I am simulating some code involving reals. > When I use ghdl and dump the data to ghw and inspect with gtkwave, the > adc_real(i) values get updated twice and then never more. > When simulating with modelsim, I see that the same code result in > adc_real values being updated with one clock cycle latency as > expected. > The integer values are updated as expected. > > What could cause reals not to be updated? > > g_dc_offset : for i in 1 to 4 generate > p_calc : process (clk) is > begin > if rising_edge(clk) then > adc_integer(i).I <= to_integer(signed(datain(i).I)); > adc_integer(i).Q <= to_integer(signed(datain(i).Q)); > --adc_real(i).I <= real(to_integer(signed(datain(i).I))); > --adc_real(i).Q <= real(to_integer(signed(datain(i).Q))); > adc_real(i).I <= real(adc_integer(i).I); > adc_real(i).Q <= real(adc_integer(i).Q); > end if; > end process; > end generate; >
There's an incomplete picture presented by your concurrent generate statement by itself. There may not necessarily be enough to reproduce your bug without extensive work. Please provide the type and subtype declarations that go with these signals, values you know aren't getting converted would help as well as the results (expected and actual). Historically Tristan has preferred a 'reproducer' a small standalone model that demonstrates a bug. I'd suspect something is getting type confused due to using record elements. Determining that would require knowing type and subtype declarations. If your sequential signal assignments in for the adc_integer are working that they are for adc_real assignments too. The model would then be giving you the same wrong result. I checked and ghdl uses 64 bit values for Universal Integers and Reals, so conversion running into truncation based on mantissa accuracy would involve big integers or type confusion. Type conversion is supposed to work between any abstract numerical types and presenting a value out of range for the target is supposed to generate an error. The generate statement contains a process, so during elaboration you'll get four block statements each with a process statement with static expressions replacing i. The signal assignment statements in each process statement are sequential and you derive the input to the real I and Q registers from the first saved integer I and Q registers (as shown with the commented lines). If your integer registers show value changes then it's not a model execution problem. There's an implicit 'wait on clk;' after the end if end statement in each process statement. I take it the generate statement contains the only drivers for adc_real(i).I and adc_real(i).Q? The preferred error reporting mechanism is through the Gna site as provided by the Report a bug link on ghdl.free.fr. Unfortunately you'll find that a Gna login is required to log a bug but it does give the developer(s) a way to contact you as well as the ability to upload a substantial amount of information you may have accumulated on a bug (like a reproducer). _______________________________________________ Ghdl-discuss mailing list Ghdl-discuss@gna.org https://mail.gna.org/listinfo/ghdl-discuss
