Continue to Site

Welcome to EDAboard.com

Welcome to our site! EDAboard.com is an international Electronics Discussion Forum focused on EDA software, circuits, schematics, books, theory, papers, asic, pld, 8051, DSP, Network, RF, Analog Design, PCB, Service Manuals... and a whole lot more! To participate you need to register. Registration is free. Click here to register now.

Tracking 'X' in the gate lavel simulation

Status
Not open for further replies.

filip.amator

Full Member level 3
Joined
Apr 30, 2017
Messages
176
Helped
35
Reputation
70
Reaction score
34
Trophy points
28
Activity points
1,047
I am trying to fix my design, it works in the ModelSim but doesn't work in the hardware. I ran gate level simulation (with the same test bench) but shortly after starting some debug at the output of the FPGA signals got 'X'. Is there any way to track where and when 'X' appears inside the design? All input data from memory are defined. I have an access to some Mentor's tools (QuestaSim, Precision Synthesis etc).
 

but shortly after starting some debug at the output of the FPGA signals got 'X'.
The manual way to find out why you see an X propagation is to go back in sim time and track down the FIRST source of X. Then find out the reason as to why that X is happening.
 

Ok, I found a source - a missing statement in a reset block.

I see in my simulation (waveform preview in Modelsim) that the half of the rising edge is blue and half of it is green. The falling edge is half red and half green (the vertical bar which depicts edge of the digital waveform is red at the top and green at the bottom). How to interpret this result of the simulation? The value of the signal between edges is green (=has got a value).
This piece of logic is interfaced to the model of the SRAM memory.
 

You've been here more than long enough to know that...

A picture is worth way more than all that verbiage you posted and posting the code along with the picture would likely be much more likely to get an answer.
 

I find the "missing statement in a reset block" kind of creepy.
Reset should be pin-applied signal and nothing but, else you
may have a simulation that works and a physical result that
doesn't, or not consistently.

The small delay is probably some marched-out initial condition
(saying that reset wasn't happening as completely as it has
to).
 

Status
Not open for further replies.

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top