UPGRADE YOUR BROWSER

We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

cancel
Showing results for 
Search instead for 
Did you mean: 
Visitor gccinac
Visitor
7,591 Views
Registered: ‎07-28-2013

Simulation vs. Reality

Jump to solution

Hello everyone!

 

I'm having some troubles after synthesizing/uploading my design to an Spartan 3e.

 

I'll introduce you to my design: Basically, I'm getting random bits which I have to get in some way into the computer. I decided to use the RS232 of the board (is there any other better/simpler way?). I'm getting the random bits correctly into the what I called rs232_e entity, so I suppose that the problem lies on this rs232 entity.

 

What this entity is supposed to do is either send data to the computer or receive data from other blocks of the fpga (rxOtx_s indicates this). If it is on receive, then it should get each Rand_i if there is BitReady_i and locate each one until completing 8 bits. Then the transmission will begin (rxOtx_s = 1)

 

I've been using Chipscope and I'm getting quite weird stuff: In some periods while on receiving, the board samples more bits than it should (some times 9 instead of 8) and then suddenly things go even worse (it samples just one random bit).

 

Here I present some images of chipscope:

After switching the reset everything works more or less fine

just_after_reset.PNG

 

 

more or less, because in point 8460 the board is sampling 9 times instead of 8!!

just_after_the_reset_detail_9_samples.PNG

 

and then, during normal work... it is simply not sampling!

after_some_time_does_not_sample.PNG

 

I've been dealing with this for some days, and as the simulation is working fine, I suppose that the problem lies on the coding of the rs232 and the simplifications that ISE does. Any ideas why is this not working? any ideas how should I code this in a better way?

 

I'll upload the code of the rs232 entity.

 

Thank you very much for any help that you could give me.

 

 

 

 

0 Kudos
1 Solution

Accepted Solutions
Advisor eilert
Advisor
9,773 Views
Registered: ‎08-14-2007

Re: Simulation vs. Reality

Jump to solution

Hi,

yes, the code looks a lot better now. :-)

 

For the bitready_i signal you don't need just one but at least two flipflops in a row.

A single FF could become metastable for some time, but the second one diminishes the probability of such an event to a neglectible value, thus ensuring a stable synchronous signal at its output.

You can read a lot about this in all the threads concerning metastability or asynchronous inputs.

 

Have a nice synthesis

 

0 Kudos
10 Replies
Historian
Historian
7,583 Views
Registered: ‎02-25-2008

Re: Simulation vs. Reality

Jump to solution

@gccinac wrote:

 

I've been dealing with this for some days, and as the simulation is working fine.

 


What is the proof of your assertion that the "simulation is working fine?"

 

Do you have proper models of the things which talk to the FPGA? Or are you essentially bit-banging the inputs and watching the outputs?

----------------------------Yes, I do this for a living.
0 Kudos
Teacher rcingham
Teacher
7,565 Views
Registered: ‎09-09-2010

Re: Simulation vs. Reality

Jump to solution
Clearly it is reality that is at fault here, and should be terminated!
;-)

------------------------------------------
"If it don't work in simulation, it won't work on the board."
0 Kudos
Visitor gccinac
Visitor
7,561 Views
Registered: ‎07-28-2013

Re: Simulation vs. Reality

Jump to solution

Hi bassman59,

 

Nope, I don't have such models. Does that mean, doing a testbench in which the inputs to the entity are as similar as possible to reality or do you mean something different?

 

Thanks a lot.

0 Kudos
Advisor eilert
Advisor
7,556 Views
Registered: ‎08-14-2007

Re: Simulation vs. Reality

Jump to solution

Hi,

where does bitready_i come from?

Together with rx0tx_s it enables the reading sequence.

Since it is '1' by default a little jitter between these signals can cause a false Enable.

Also, it controlls your (implicit) FSM but comes in asynchronous.

This can cause certain problems. At least you should synchronize it with some FFs to the clock rate of the process.

 

In your code the ninth sample may overwrite the 1st sample.

 

You can simplify and make your code more robust if you reset the selection vector at the beginning of the transmission:

 

 

    elsif (CP_i'event and CP_i = '1') then
      if (rxOtx_s = '0') then
        Serialout_o <= '1';
        if (BitReady_i = '1') then
          ReadAck_o <= '1'; 
          if (selreg_s = "0000") then    -- a 'case' would be nicer here
            reg_s(0) <= Rand_i;
          elsif (selreg_s = "0001") then
            reg_s(1) <= Rand_i;
          elsif (selreg_s = "0010") then
            reg_s(2) <= Rand_i;
          elsif (selreg_s = "0011") then
            reg_s(3) <= Rand_i;
          elsif (selreg_s = "0100") then
            reg_s(4) <= Rand_i;
          elsif (selreg_s = "0101") then
            reg_s(5) <= Rand_i;
          elsif (selreg_s = "0110") then
            reg_s(6) <= Rand_i;
          elsif (selreg_s = "0111") then
            reg_s(7) <= Rand_i;
            rxOtx_s  <= '1';
          end if;
        selreg_s <= selreg_s +1;   -- only one increment line needed
        elsif (BitReady_i = '0') then
          ReadAck_o <= '0';
        end if;
      elsif (rxOtx_s = '1') then
        selreg_s <= "0000";       -- reset selreg when not in use
        ReadAck_o <= '0';

 

The same holds for the transmission part.

You wasted about 30 % of codelines, which makes your code more difficult and time consuming to read.

 

 

 

Have a nice synthesis (and simulation too)

   Eilert

 

 

0 Kudos
Visitor gccinac
Visitor
7,545 Views
Registered: ‎07-28-2013

Re: Simulation vs. Reality

Jump to solution

Hi eilert! Thanks a lot for the answer!

 

I've simplyfied the code following the directives that you gave me. It certanly looks much better (I attach it just in case).

 

It could be something related to the bitready_i input as you say: It is an asynchronous input (it cannot be otherwise) and each time a new randbit_i is latched, bitready goes active. Then, the rs232 entity, on the next clock edge, activates the asynchronous reset of the FF where  bitready is stored, so bitready_i goes to 0 until the next randbit_i is latched.

 

Should I hold the value of bitready with a FF which is synchronized with the clock of the process, is that what you mean when you said "At least you should synchronize it with some FFs to the clock rate of the process."? 

 

Thanks a lot

 

0 Kudos
Highlighted
Historian
Historian
7,539 Views
Registered: ‎02-25-2008

Re: Simulation vs. Reality

Jump to solution

@gccinac wrote:

Hi bassman59,

 

Nope, I don't have such models. Does that mean, doing a testbench in which the inputs to the entity are as similar as possible to reality or do you mean something different?


YES.

 

That is EXACTLY what I mean.

 

So if you're trying to test your UART implementation, you need a known-good model of a UART against which to test. Your transmitter talks to the model receiver; your receiver gets its input from the model transmitter.

 

If you were testing an SDRAM controller, you'd need to use models of the SDRAM devices in your system (and these models are generally available).

 

A lot of my designs have ADCs which supply data over a variety of interfaces. So I've either obtained or more likely written bus-functional models of the converters. Thus I can verify my data handling. (Note I said "verify," not "simulate.")

 

I recently finished a camera design, and the sensor vendor provides bus-functional models of their products, which I used to verify my interface design.

 

I wrote a model of the Camera Link receiver chips, so I could verify my Camera Link transmitter design. (In fact, the full test bench includes everything: the sensor model, the FPGA, the Camera Link receiver, some other things required by the system, etc etc. Can't run it in the free tools, though: you've gotta spring the bucks for a non-hamstrung simulation tool.)

 

Now let me clarify: a simulation model doesn't need to be synthesizable. It's the behavior you're modeling. You need the interfaces to work like the real thing. This gives you great flexibility in how you code your models.

 

Oh, and yes, looking for and creating proper models takes time. Writing a proper test bench takes time. But by doing that work up front, it saves days off of your debug time in the lab.

----------------------------Yes, I do this for a living.
0 Kudos
Visitor gccinac
Visitor
7,532 Views
Registered: ‎07-28-2013

Re: Simulation vs. Reality

Jump to solution

Hello!

 

The thing is that my input is supposed to be random, thus I cannot simulate such models with the precission required.

0 Kudos
Historian
Historian
7,530 Views
Registered: ‎02-25-2008

Re: Simulation vs. Reality

Jump to solution

@gccinac wrote:

Hello!

 

The thing is that my input is supposed to be random, thus I cannot simulate such models with the precission required.


While the data going across the wires can be random (and can be modeled, see here), the peripherals acting as data sources and sinks most certainly are not. Their interfaces had better be well defined, otherwise your design can't talk to them.

----------------------------Yes, I do this for a living.
Advisor eilert
Advisor
9,774 Views
Registered: ‎08-14-2007

Re: Simulation vs. Reality

Jump to solution

Hi,

yes, the code looks a lot better now. :-)

 

For the bitready_i signal you don't need just one but at least two flipflops in a row.

A single FF could become metastable for some time, but the second one diminishes the probability of such an event to a neglectible value, thus ensuring a stable synchronous signal at its output.

You can read a lot about this in all the threads concerning metastability or asynchronous inputs.

 

Have a nice synthesis

 

0 Kudos
Visitor gccinac
Visitor
2,249 Views
Registered: ‎07-28-2013

Re: Simulation vs. Reality

Jump to solution

Hi eilert!

 

Again, thank you very much for the answer! It seems it is working!

 

At first I tried using 1 FF and it didn't work (as you predicted), but then I used 2 FF as you said and it seems it is working as expected! I'll read some threads about metastability as you suggested, it definitely seems to be quite an important topic

 

Thanks a lot!

0 Kudos