On Saturday, June 25, 2011 23:29:54 David G. Koontz wrote: > On 26/06/11 3:21 PM, Wesley J. Landaker wrote: > > On 06/25/2011 02:51 PM, Wesley J. Landaker wrote: > >> I've found a strange bug with GHDL and buffer ports. > > > > On more investigation, this seems to be a bug with "bit", not buffer > > ports. If I switch to using numeric_std and std_ulogic and change > > nothing else it starts to work. > > > > So still a bug, just in a different place than I first thought. > > Out of curiosity, how did you pursue this architecture in the first > place?
Well, I use GHDL daily for real work -- and thought that I had found a bug in a huge fully synthesizable design, but it didn't show up in other (annoying, proprietary) simulators. So I very slowly tracked this down over several hours to GHDL misbehaving. > It appears to pivot on the use of a variable for val and combining the > operation of the val counter in the same process as a sequential > assertion statement (because val is a variable). Well, the wait and the assertion (and to_integer, etc) don't have anything to do with the bug, they are just there to help demonstrate it in a small test case. In the real design where I found this, a numeric_bit unsigned buffer port is driven synchronously in one process, and read in another combinational one. The symptom is that it randomly gets reset to zero *during the combinational process that just reads it*. At first I thought the problem was GHDL's handling of buffer ports, because I fixed it by changing that one instance to an out, but I've since found that it's the use of bit (at least via numeric_bit.unsigned). The reason my original fix worked (and thus my hasty misdiagnosis) is because when changing to an out, I had to add an intermediate signal due to VHDL port rules. > Make val a signal and you can get the code to work without an extra wait > statement, with num as a bit. I've already got a work-around. Now I'm just trying to help identify the bug in GHDL so that, once fixed, this doesn't continually bite me or others in the future. =) Also, I can't (easily) change the code in question just to work around GHDL bugs. So better to try to get GHDL fixed when something comes up than be forced to abandon it for this project and be stuck with a less desirable (annoying, proprietary) development environment. > Because in general wait for delays are not synthesizable, timed model > comparisons aren't really an issue. Your model isn't particularly > interesting for 'hardware'. Yes, wait delays are not synthesizable, but 1) that's not the bug here, and 2) they *are* very interesting for hardware, because things need to be tested and external components modeled, and tests and models must use non- synthesizable code all the time. > Why switching num to numeric_std would also work isn't particularly > intuitive to me. This shows up in the Mac OS X mcode version too. The underlying cause is something to do with bits (or, at least, numeric_bit unsigned bit vectors) going between two processes. I haven't got to the bottom of it completely yet, but I was hoping Tristan or someone more familiar with the GHDL codebase than me would be able to help pinpoint the problem. To that end, if it is valuable for me to make some further demonstrative test cases for this bug, I would be happy to do so. _______________________________________________ Ghdl-discuss mailing list [email protected] https://mail.gna.org/listinfo/ghdl-discuss
