cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
pragavish
Observer
Observer
2,472 Views
Registered: ‎04-22-2018

Chipscope displaying signal incorrectly in vivado

Hi,

 I created a project involving Artix 7 FPGA (xc7a200tfbg676-1)  in the environment Vivado 2020.2.

In the testing phase, while checking a macro , I found that random signals were displaying as "high" in the CHipscope Logic Analyzer, eventhough i have set the signal to be "Low" in both reset and initialising phases. So to check the authenticity, I routed that particular signal to a read register and even took that signal in chipscope. That register signal was displayed to be "Low" as it should have been.            

There are no timing errors in the design.

For reference i have attached Two images :

 First image : in that "us_4_5_en" is the signal that is "high" even though it should be low. That signal is routed to another register "read_temp[2]". That signal is low as intended.

 2nd  image : this image is during the functioning of the macro. Random toggle of signals are seen in "us_4_5_en". Whereas "read_temp[2]" displays the correct toggling of the signal.

I even routed us_4_5_en signal to an external pin and probed using a scope and found to be OK, but only the signal displayed in chipscope seems to be like that

Please provide a solution of why some signals behave like that.

 

Thanks

IMG-20210204-WA0002.jpg
IMG-20210204-WA0003.jpg
0 Kudos
36 Replies
maps-mpls
Mentor
Mentor
2,077 Views
Registered: ‎06-20-2017

The symptoms you've taken the time to describe are insufficient to come up with a solution.  You'd probably want to share some of your source code.  Specifically we would need at least your HDL for us_4_5_en and read_temp[2:0].  Is the enable controlling a tri-state?

Also, although it is just a label, and this is a minor nit, it looks like you're using Vivado logic analyzer and not chipscope.

Next, how are you selecting the nets for debug?  Post synthesis?  MARK_DEBUG attributes? 

The first thing you should check when using VLA, after clock and reset both seem good, is whether you have generated and also downloaded the latest bitstream to your device.

I suspect that if you post the RTL that produce the above, we will be able to come up with a reasonable solution.  But there is no way to know until you post it.

*** Destination: Rapid design and development cycles ***
0 Kudos
drjohnsmith
Teacher
Teacher
2,058 Views
Registered: ‎07-09-2009

How does the ILA output compare to the simulation ?

If the pre synthesis looks ok, then try the post synthesis

Till you have simulated and proven the signals, you can not move onto synthesis with any level of confidence what you have does what you want,

  

 

<== If this was helpful, please feel free to give Kudos, and close if it answers your question ==>
0 Kudos
pragavish
Observer
Observer
1,996 Views
Registered: ‎04-22-2018

1.) Is the enable controlling a tri-state?

       No, the enable is not controlling a tri-state. The "us_4_5_en" signal is made "1" only in one state of a FSM and in all other states it is '0'. Just for the sake of debugging I just assigned us_4_5_en to another signal called read_temp[2]. And us_4_5_en is just used for starting a macro which is another FSM where I would be starting the macro when is receive "1" in that signal. I have attached the image where i am using the signal.

2.) how are you selecting the nets for debug? Post synthesis? MARK_DEBUG attributes? 

  The signal in question (us_4_5_en) is selected only in post synthesis and have not used MARK_DEBUG attributes. But some other signals I have used in mark_debug attributes.

3.) is whether you have generated and also downloaded the latest bitstream to your device

Yes , I have rechecked it  and have generated and downloaded the latest bitstream to the device.

 

IMG-20210205-WA0002.jpg
IMG-20210205-WA0003.jpg
0 Kudos
drjohnsmith
Teacher
Teacher
1,963 Views
Registered: ‎07-09-2009

And the simulation ?

 

 

<== If this was helpful, please feel free to give Kudos, and close if it answers your question ==>
0 Kudos
pragavish
Observer
Observer
1,938 Views
Registered: ‎04-22-2018

Yes I did the post synthesis Functional simulation and found that the "us_4_5_en" is high. But when i looked at the LUT connection, it seems that read_temp[2] is connected to the enable signal and the us_4_5_en is high continuously. In the image consisting LUT  I3 is the signal "us_4_5_en" and I4 is the signal "read_temp[2]".

In the first image the notepad consists of input signals of a LUT whose output is "us_4_5_en". All those values are 0 and in that LUT truth table it was mentioned as when all these are "0" O/P (us_4_5_en) is "1". 

IMG-20210205-WA0016.jpg
IMG-20210205-WA0015.jpg
IMG-20210205-WA0014.jpg
0 Kudos
drjohnsmith
Teacher
Teacher
1,919 Views
Registered: ‎07-09-2009

The conclusion is then

 that the simulation and the ILA both agree, both say the signal should be and is high ?

   which is good news,

So you now need to debug your code and find out why the output is wrong.

   I'd suggest that you check the pre synthesis code in simulation, and also look for warnings in the synthesis code, see what has been removed that you do not think should have been.

Is the language VHDL ? if so this can be caused by sensitivity list errors, which will be flagged as a warning during synthesis .

 

<== If this was helpful, please feel free to give Kudos, and close if it answers your question ==>
0 Kudos
pragavish
Observer
Observer
1,882 Views
Registered: ‎04-22-2018

When i give the signal "us_4_5_en" in mark_debug attribute that signal now seems to be working as intended. any relation between them then?

0 Kudos
drjohnsmith
Teacher
Teacher
1,851 Views
Registered: ‎07-09-2009

   in both cases the signllls to the outside world work as you intend ?

       when you say dont optimise this signal away , its there,

So what you asking ?

 

<== If this was helpful, please feel free to give Kudos, and close if it answers your question ==>
0 Kudos
xlyns
Adventurer
Adventurer
1,840 Views
Registered: ‎01-09-2018

see last reply please

 

I have to say I see nothing wrong here,

Firstly,

if you tell the synthesis to drive the signal HIGH in one specific condition, all other situations should be tied to LOW and if not you got dangling signals that are chosen at random by the synthesis machine that optimizes what you defined and is doin what it feels best on what you did not define. People should think like the synthesis engine and simply optimize what is told to it, I would only tell it whgen things need to be HIGH and make sure everyother situation is tied to LOW.

Secondly,

If you dont trust Chipscope do not use a logic analyzer because they could pick up noize or EMF confusing you even more

Third,

If you can simply overclock a BRAM/blockram and record the signals you want to observe and then read out your BRAM you might have the most accurate values and you could even repeat the experiment using a hairblower to reach 150 Degrees Celsius and some Icing spray for the -40 Degrees and repeat the experiment to have the real true values recorded over the temperature span that will change the timing characteristics.

This methods is used in the industry where safety is very important and I do not see any other better way to make sure 

 

 

 

0 Kudos
maps-mpls
Mentor
Mentor
1,788 Views
Registered: ‎06-20-2017

Did you really take a photo and then upload the photos?  Maybe if you had printed it and then scanned it it would have looked even worse:)

 

Anyway, next type I'd recommend inserting your code using the insert code </> ideograph.

maps-mpls_0-1612636497864.png

Also, if you want even better help (others here have been giving you good advice), just paste your whole module.  It doesn't look like it is anything anybody else would steal, and you might get some very valuable feedback.

 

*** Destination: Rapid design and development cycles ***
avrumw
Guide
Guide
1,735 Views
Registered: ‎01-23-2009

I have to disagree with some of the points made by @xlyns ...

if you tell the synthesis to drive the signal HIGH in one specific condition, all other situations should be tied to LOW and if not you got dangling signals that are chosen at random by the synthesis machine that optimizes what you defined and is doin what it feels best on what you did not define.

This just isn't true.

A signal that is not defined in all branches of an if/case does is not "dangling" and not give the tool freedom to do random assignments - the result of this operation is fully deterministic.

First of all, if this is in a combinatorial process, then there are two cases:

  • If the signal is assigned a value before the if/case statements - this is the default. Unless overridden by one of the if/case clauses, the value will be the default
    • This is normal coding style and is perfectly acceptable
  • If the signal has no default in the combinatorial process and is not assigned in all branches of the if/case, then the tools will infer a latch
    • Generally latch inference is done by mistake and the tools will flag it as a warning

If this a clocked process (and while we can't see the top of the process I highly suspect that it is) then the lack of assignment of a signal in one or more branches (and no default value) specifically codes for "Do not update the value of this flip-flop on this clock edge" - hold the current value. This is completely legal and even encouraged syntax.

If you dont trust Chipscope do not use a logic analyzer because they could pick up noize or EMF confusing you even more

I'm not sure if this statement is referring to the Vivado ILA (which was previously called ChipScope in the ISE days) or is talking about an external logic analyzer. I will assume it is talking about the Vivado ILA. The Vivado ILA is an "Internal Logic Analyzer". It is an digital and synchronous IP core that is added to your design to monitor the values of selected signals. When enabled, this synchronous state machine looks for specific trigger sequences, and when detected starts storing the signals (or filtered subsets of the signals) to be read out later. The stored signals are, in fact, placed in BRAMs which are part of the ILA (as is suggested later). This added logic is digital and synchronous and timed like any other part of your design. It is no more (or no less) susceptible to noise than the rest of your design (since it is implemented using the exact same process and mechanisms as the rest of your design) - if you don't trust the Vivado ILA, you don't trust FPGA based designs - they are one and the same thing.

The only "difference" with an ILA is that it uses a backdoor (JTAG through the ICAP) to control the enabling of the ILA and to read back the data stored in the BRAM at the end of a capture. Again, this is completely reliable.

 you could even repeat the experiment using a hairblower to reach 150 Degrees Celsius and some Icing spray for the -40 

DON'T EVER EVER DO THIS!

First, the absolute maximum die temperature for these devices are in the 120C-125C range (depending on device) - and this is the maximum die temperature; if your case is 150C then (if your device is operating) the die temperature will be above (maybe even well above) this. If you exceed the maximum die temperature, the device could be permanently damaged, and even if it survives should be discarded.

Furthermore the maximum operating temperature of an FPGA is 85C or 100C depending on your device (commercial or industrial grade). The moment your die exceeds this temperature, the device is not guaranteed to perform properly - in fact it is expected to behave incorrectly. So capturing incorrect values at this temperature shows nothing...

Avrum

pragavish
Observer
Observer
1,650 Views
Registered: ‎04-22-2018

@avrumw  @maps-mpls  @drjohnsmith I have attached the module for reference. This is the file in which the "us_4_5_en" is in default high condition

Thanks

0 Kudos
drjohnsmith
Teacher
Teacher
1,627 Views
Registered: ‎07-09-2009

Bit of a monster of a state machine !!

On a style note, I'd be tempted to put it in a separate entity, 

      ALSO My big gripe,   

look at your libraries

library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.STD_LOGIC_ARITH.ALL;
use IEEE.STD_lOGIC_UNSIGNED.ALL;

https://www.nandland.com/articles/std_logic_arith_vs_numeric_std.html

https://insights.sigasi.com/tech/deprecated-ieee-libraries/

http://www.synthworks.com/papers/vhdl_math_tricks_mapld_2003.pdf

 

As for the code, 

   apart from this bit

when PRE4_5H =>
pre_cnt <= pre_cnt + 1;
us_4_5_en <= '0';

which is not needed ( you set it 0 in the default section ) 

without gogin deep into the code and simulaton , no blindingly obvious blunders,

 

Remind us again what the problem is please ?

   You have a system that simulates fine , both in pre and post synthesis ?

 

<== If this was helpful, please feel free to give Kudos, and close if it answers your question ==>
0 Kudos
pragavish
Observer
Observer
1,612 Views
Registered: ‎04-22-2018

Remind us again what the problem is please ?

The problem is that the signal "us_4_5_en " is in default high condition(the image is in above replies) even during the reset state and even when the FSM starts functioning.

I viewed this problem only in post synthesis simulation and vivado logic analyzer. SO i want to know why that signal is behaving so?

 

Thanks

pragavish
Observer
Observer
1,609 Views
Registered: ‎04-22-2018

Bit of a monster of a state machine !!

On a style note, I'd be tempted to put it in a separate entity

Haha yes it is. It is one continuous checking design where i have to check all the parameters at one go. Yes necessary functions i have seperated and used as a individual macro which I have instantiated. Do the libraries would have caused problems?

maps-mpls
Mentor
Mentor
1,589 Views
Registered: ‎06-20-2017

  1. You have a synchronous reset in the process labeled TTL_POS_VALID.  Consequently, putting the reset in the sensitivity list is pointless, and may make some simulators run slower.
  2. pre_cnt is a std_logic_vector, but you are using synopsis squatter packages (packages that were not approved by the IEEE but were made to appear in the IEEE library).  Get rid of std_logic_arith and std_logic_unsigned packages.  Declare pre_cnt as an integer range 0 to whatever.  This will be a painful process if it is your first time due to your use of + and * operators on std_logic_vector.  Better to use type unsigned from numeric_std package in most cases, instead of std_logic_vector.  And then when you convert to std_logic_vector (for output or port mapping), cast the unsigned as std_logic_vector.  E.g., slv_output <= std_logic_vector(unsigned_reg);
  3. Consider moving pre_cnt out of the state machine, and having it increment when the state is in one of the states where it is supposed to increment. 
  4. Your state machine can only take on a finite number of enumerated values.  Your case statement fully enumerates every value.  Consequently, your use of “when others =>” is pointless.  If you are trying to construct a safe state machine, please refer to user guide 901 in DocNav.
  5. Your state machine is far too complex.  It looks like a typical (and a lot of us have done this) design by simulation waveform state machine.
  6. Consider trying to draw a state transition table.  Look for common behaviors in common states.  It is okay to break your state machine into multiple states.
  7. Create a type 
      type tSampArray IS ARRAY(0 to 11) of std_logic_vector(SQTR_D31'range);   
      signal  sample_lvl  :tSampArray:=  (others => (others => '0'));​
    
    
    ....
    
                sample_lvl(0) <= SQTR_D31;
    
  8. You have data flow built into your state machine.  This can (and does in my opinion) lead to both timing problems and a young designer getting weeds wrapped up in the spokes.  Consider moving all data flow assignments outside of your state machine based on conditions, and that process of making this change may lead you to design a simpler state machine with reduced number of conditions when registers are loaded. 
  9. Make sure you are not inferring CE functionality on reset by making sure everything on the left hand side of an assignment in the else of the reset conditional is also on the left hand side of a literal assignment in the if of the reset conditional.
  10. Move your state machine to its own entity/architecture.
  11. Your architecture is labeled behavioral but is actually mixed (structural and behavioral).  Make your architecture label more meaningful, or just label it “a1”.

If you try 3, 6, 7, and 8 first.  I suspect you will solve your own problem (or prove there is a bug in the tools).  (I also still wonder if your bitstream and probe files are up to date, and in sync with each other).

*** Destination: Rapid design and development cycles ***
drjohnsmith
Teacher
Teacher
1,577 Views
Registered: ‎07-09-2009

so back into the simulator,

   follow the state machine , see where it goes , does that signal ever change .

Then check has the signal been optimised away in the synthesis ?

   then check th epost synthesis simulaiotn, does that still work ?

 

Signals as Im afraid we have said, are optimised away by the synthesiser. 

    The way to debug is to look at the simulation, follow the logic, 

 

 

   

 

<== If this was helpful, please feel free to give Kudos, and close if it answers your question ==>
0 Kudos
drjohnsmith
Teacher
Teacher
1,571 Views
Registered: ‎07-09-2009

Also remember ,

  errors in sensitivity lists cause difference between simulation and synthesis,

    You need to check your warnings

 

As for the packages issue, I posted some links, you mix packages from different places at your own risk , remember the synthesis and the simulator might understand a packages diferently 

     especially true if the packages , as you are using, over load each other.

Unless you are an expert on the packages, only use the IEEE ones. 

 

<== If this was helpful, please feel free to give Kudos, and close if it answers your question ==>
0 Kudos
xlyns
Adventurer
Adventurer
1,475 Views
Registered: ‎01-09-2018

see last reply please

 

First

 

I wish to repeat my points that may not have been well formulated avrum, I apologize for not having explained it enough. 

I got 20 years hands on experience with the tools and am knowing what I am doing more than how to communicate

You seem to know what the tools does - good for you but before Vivado ISE was actually different slightly,

and even between ISE versions was differences, the idea of the designer is to guess what the synthesis guys decided and vice versa

The idea of HDL is Highly Descriptive Hardware Language - to define exactly the building structural one is wanting or in RTL the behavioral

You say that if something is not defined its fine, in fact I agree but anything undefined allows the synthesis to optimize the way it wants legally?

If I say when B = 1 I want A = 1 its going to deliver A s/1 because its the simplest, 

If I say when B = 1 A= 1 and when B=0 A=0 then its going to deliver A=B,

Here I am talking in logical terms - legally what is described is what one gets

You say there is the courtesy of Xilinx to assume that what is defined in the default state will be the tied state for all undefined situations what if the situations do not care and its a waste of ressources?

I doubt the courtesy of Xilinx is to waste of resources so I am just expressing that the user should expect what he is asking for in a Highly Descriptive Articulate way (HDL Highly Descriptive Language)

In the software world it is also considered a bad practice to leave things dangling if they matter but ok it they dont care

 

 

Second

 

Yes I see the point with JTAG the status of all registers is read out on each cycle

oh wait that means...

things happening at time alpha = 0.00000000000nS

clock edge happens at say alpha + delta =  10.00001234nS for 100Mhs

next clock happens at say alpha + 2 delta =  20.0009784nS for 100Mhs

now I want to know if in between that the setup (before time) and hold (after time ) time is good  how can I manage that if I use the JTAG that takes ages its boundary scan between all registers hence can take seconds ?

so they scan all registers for seconds before then run the clock once and scan again for seconds so its showing the situation recorded by the registers between 2 clocks 

In my situation im adding the track time between all registers and the BRAM because if the clock is happening there at time alpha = 10.00000nS the next alpha will be 20.0000nS because the BRAM timing is the home timing its the time where the data is delivered and retrieved locally whereas the register will have his own little delta skew and the mistake is to say ok lets look at Register 1 with skew say 0.00001234nS and  Register 2 with skew say 0.00046734nS (values are fictious just for the example) then the JTAG will gather mix max times values whereas if all is recorded by the BRAM its the BRAM time that will be central and the same for each observed register. So if Register 1 is very close and Register 2 real far and skewed then you got still the values of both exactly in the same time that is relevant to the BRAM

So the time is central for all. 

Imagine like having 2 referees with 2 stop watches that differ slightly and then on touchdown one is showing overtime and the other not?

And using an external Logic Analyzer would be as if the referees would be in New York and would not be on the field that is also not very wise?

I beleive its is more accurate to use the BRAM and overclock it and gather all signals centrally to its clock edge, its giving a photograph of exactly all the signals at the same exact time and don't forget that the JTAG takes up to billions of clocks also, I have actually captured metastable behaviors and Chipscope would have never seen it because after a certain number of clocks it can be stable again and you see nothing

 

Third

 

20 years ago the FPGA just came out so the company building airplanes had to upgrade the CPLD, 

Did you already think of what it means to test a device that has to work 20 years with no failure at least - so far that airplane model never had a single casualty and I'm relieved, as engineer one is exposed to situations that often are haunting when one is unsure so its best to test more than less: 

here the thoughts

the automotive specification is -40 to 125 Degrees but even the best monte carlo simulations would not show all what can go wrong in the different timing situations when going from one temperature to the other rapidly - which is the worst case. Per example the plane flying 50000 feet and freezing temperatures and landing in a desert at 120 degrees and added heat from the engines etc.. would be 125 degrees.

this fast change in temperature one can hardly simulate so its good to make a real test also, but the is additionally to the temperature another factor that can affect the timing its the cross talk and EMF that can be per example the radar waves from the airfield, and roughly speaking even at 125 the delays could be as severe as if it was 150 degrees if we add the leaway for such added disturbances - external waves or internal and leakage currents induced by who knows. So to be sure a chip is good 

In fact most automotive go untill 135 degrees but for space flight or aircrafts 150 degrees - its true Xilinx is less in this end than ACTEL but its amazing that I found the Xilinx FPGA still good after that temperature in the test

here the description from ACTEL  I found there https://www.eejournal.com/article/20050906_actel/ its the same as I had 20 years ago 

@After the package tests are completed, electrical testing is performed, and then dynamic burn. During the burn-in, devices are located on specially designed burn-in boards in a temperature chamber. The devices are powered-up and operating with special test patterns during the burn-in, hence the term dynamic burn-in is used to describe this testing. Mil-Std 883 Class B allows manufacturers to perform the dynamic burn-in at either 125ºC for 160 hours, or 150ºC for 80 hours. With the decreasing maximum junction temperatures of today’s advanced deep sub-micron fabrication processes, most manufacturers today are performing dynamic burn-in using the 125ºC / 160 hours option. Following dynamic burn-in, electrical parameters are measured again, and then a suite of electrical tests are performed at the extremes of the military temperature range as well as at room temperature. Strict rules govern the acceptability of a lot, so any failures during the testing are recorded. If more than a specific, small number of failures occur, the entire lot will be rejected and will not be shipped to customers.

I do apologize that when I mentioned 150 degrees it was for the ACTEL but I think Xilinx chips can withstand that for short because I did that a lot to test the timing and make sure I have some good choice of the clock frequency with respect to the area / and temperature range test, but in engineering there is nothing wrong to push things to their limits its more an issue in the hands of the client when its then unreliable

What I am saying here is that the simulation are one side of the test but ultimately there is the real life functional testing that got toi drive the device to its limits

 

I am sorry if I did not express the points well, but I was thinking there could be either reasons for the dangling 1, or the underspecified code leaving the synthesis engine to choose the best or some serious timing issues thats would be exacerbated if one would temperature test or it could also be the JTAG going through a faulty element and therefor the chip could be damaged by ESD EMF or other factors specially if the behavior would noit be found using another method  - external probes. internal BRAM overclocked etc..?

I am really confident its one of the three that is the issue, under-specification, mis-timing or de-fect.

0 Kudos
drjohnsmith
Teacher
Teacher
1,442 Views
Registered: ‎07-09-2009

Thats quiet a long lot of text for us to read on the phone,

 

Can I just take on little bit of it

"The idea of HDL is Highly Descriptive Hardware Language - to define exactly the building structural one is wanting or in RTL the behavioral"

This is wrong, 

 

HDL is "Hardware Description Language"

You are describing the hardware, 

    Think of it as the C code you write, you are describing the actions you wan tot happen, 

            If you look at the C compiler output , it has totlay chnaged what you put , I find in to ways that are amazing,

                 but what matters is the C compiler has made the code more efficient, and still kept the actions to the outside world the same.

    Look at it another way,

       If you had two different CPUs one say ARM one say  Microchip, that you had C code for, you could in theory compile the same C code to both, the output would look very different, 

The key is that to the user on the outside of the chip the function is the same, 

 

Same in FPGAs , the compiler is going to do some amazing tricks to fit your description into the chip

   For a start its going to chuck away any logic that does not toggle, and replace it with a constant.

    Its going to do lots of register push back / forward, lots of register / logic duplication / reduction.

To the outside, its going to look the same,

   

So the question is ,

  does this design work on the outside as you expect in simulation and in real life ?

 

 

<== If this was helpful, please feel free to give Kudos, and close if it answers your question ==>
xlyns
Adventurer
Adventurer
1,432 Views
Registered: ‎01-09-2018

see last reply please

the FPGA is synthesizing the hardware described in the code in a layout

the Software compiler create assembly code that go in the control unit of a sequential block it is nothing to do with creating a circuit

there is some C that Xilinx offers to synthesize but its just the behavior in the code its turning into hardware

I wrote  The idea of HDL is Highly Descriptive Hardware Language - to define exactly the building structural one is wanting or in RTL the behavioral"

because in HDL you can describe the hardware block per block (Flip Flop Logic gate wire mux and so on) and its called Structural HDL (VHDL or Verilog )

or you describe the RTL telling what is happening  in logical terms and its is called Behavioral HDL  (VHDL or Verilog )

so yes I apologize HDL is Hardware Description Language but in effect it is a  Highly Descriptive Hardware Language

I hope I can help I'm not too communication expert articulate but I have a lot of hands on and I think I understand what the FPGA does well enough to be sure of how it works (when timing is right otherwise no one can understand what it does)

 

0 Kudos
drjohnsmith
Teacher
Teacher
1,420 Views
Registered: ‎07-09-2009

The key part,

   If you write C code for a CPU, then after compilation, any variable you use may not be in the final code. its optimised away.

Same for FPGAs, 

    

<== If this was helpful, please feel free to give Kudos, and close if it answers your question ==>
xlyns
Adventurer
Adventurer
1,314 Views
Registered: ‎01-09-2018

writing the thoughts that

- anything unspecified by code is leaving the door open for the synthesis machine to do what it wants so it may do erratic things in unspecified areas because they are not specified. 

- another possible source for erratic signals is timing and a good way to check is to see if the behavior is same at -40 degrees and 150 degree Celsius (i.e. automotive industrial spec)

note: to represent the worst case of additional EMF, you can stick to 125 degrees Celsius but have to induce and expose to EMF scenarios then that will cost you several million $ in equipment's so I  add 25 degrees to spec to create more disturbances by heat that are in lieu of the EMF situation, this is in any case better than any simulations because it is testing in real your system

- for what I suggested with the BRAM overclocking to the max safe frequency and centrally registering all signals one is interested in, it would yield better timing waveforms for my perspective because its then showing everything from one single time and space unity capturing the dynamic behaviors that Chipscope cant. If as Chipscope the JTAG captures all signals each clock is in effect frozen in time (post editing note : the data isn't frozen and Chipscope lets it settle which is not the true dynamic behavior ) for the JTAG to shift the data back to memory hence one captures the static behavior not what is dynamically going on. So what I do is bypass the JTAG that gathers sequentially and slowly the signals and instead gather all in parallel on the BRAM. So its showing the real things happening not the static that is letting all settle but isn't realistic because the setup and hold have all the time in the world with the slow JTAG

The answer to the question is, yes, Chipscope displays signal incorrectly for the reasons mentioned here because its never going to be the real dynamic behavior.

Using the BRAM to capture in real time works much better and is easy to implement and Xiling done an excellent job in making the timing of the routing very reliable so its then able to capture what is going on dynamically

0 Kudos
avrumw
Guide
Guide
1,194 Views
Registered: ‎01-23-2009

- anything unspecified by code is leaving the door open for the synthesis machine to do what it wants so it may do erratic things in unspecified areas because they are not specified. 

There are very few cases where you can write code that allows the synthesis tool any freedom

  • The signals involved in a state machine for a state that is not defined
    • Here, if the tool does state machine extraction and recoding (and only if it does state machine extraction and recoding), it is free to allocate the values for unmapped states
    • By definition these should not affect functionality since the state is never used (which is why this recoding is legal)
  • Explicitly defining a value to the unknown state (value of x in Verilog)
    • In which case you are telling the tool explicitly that it is free to choose a value

All other RTL has no ambiguity. The rules of Verilog/SystemVerilog/VHDL are clear for all other cases - the result of a snippet of code results in known values after the execution of that code in simulation, and synthesis must match that value, unless the underlying code is not synthesizable, in which case the synthesis tool must generate an error. And to be explicit - not defining the value of a signal in all branches of an if/case is not a situation where the tool has any freedom - all such cases are either unambiguous, or will infer a latch (which is normally a coding error).

another possible source for erratic signals is timing

Yes. If your design does not meet timing, then you can get unpredictable behavior from your design. The way to prevent this is to make sure

  • You have complete and accurate timing constraints for your design
    • And this includes not having any incorrect exceptions and accurately specifying clock jitter
  • The result of static timing analysis after implementation says that you met all your constraints (i.e. it passes timing)
  • You are operating the design within the allowed range of voltage and temperature

If you have done all of this, then you will not get unpredictable results due to timing.

a good way to check is to see if the behavior is same at -40 degrees and 150 degree Celsius

If your meet all the above then you will get the same results at all legal temperature and voltages. Sure, there is no harm in trying to validate your design at the extremes of the legal temperature, but...

  • This should never (and in my experience never does) show any failures
    • Xilinx guarantees the behavior of the device under the above conditions, and each device is tested to meet its performance requirements before it leaves the factory
    • Doing this verification is basically re-checking Xilinx's qualification mechanism - and Xilinx has decades of experience in getting this right!

And if your device is specified to be operable in this range (I haven't worked with the automotive devices) then fine - you can do this. But if the device you are using is specified over a narrower range (i.e. commercial or industrial), then testing it outside its range is illegal - any failure you see are expected and shows nothing.

Another source for unpredictable behavior is bad clock domain crossing. This is probably, in fact, the most common cause of unpredictable results (although I have no reason to believe that this is the case with the original poster's code). If you do not have properly designed and constrained clock domain crossing circuits then you can have system failures. It is worth noting that heating/cooling the device will have no effect on these failures if they are between truly asynchronous clocks. It is possible for heating/cooling to show illegal/unconstrained clock domain crossings between mesochronous clocks, but, again, you must remain within the legal limits of the device. 

And there are protections in place for these kinds of failures - the report_clock_interaction command helps you identify unintentional clock domain crossings, and the report_cdc command flags what the tool sees as illegal clock domain crossing circuits.

If as Chipscope the JTAG captures all signals each clock is in effect frozen in time (post editing note : the data isn't frozen and Chipscope lets it settle which is not the true dynamic behavior )

I suspect you don't understand how the ILA works (it is no longer called Chipscope). ILA capture is live, at full frequency, while your design is operating normally. The capture is exactly as you describe for your mechanism - while the clocks are running, the data is written synchronously and at full speed to BRAMs allocated to the ILA. Once the BRAMs are full, capture stops (while your design continues to run), and the result of the capture can be read out using the JTAG connection. The ILA is simply giving you an easier mechanism of controlling what is written to the BRAM, when to start and stop writing to the BRAM, and gives an easy mechanism to read the results from the BRAM (and present them in a waveform like interface on your PC). There is no advantage to a custom written mechanism over the ILA unless you do not have access to the JTAG port.

Avrum

xlyns
Adventurer
Adventurer
805 Views
Registered: ‎01-09-2018

First

 

You say that

There are very few cases where you can write code that allows the synthesis tool any freedom:

    The signals involved in a state machine for a state that is not defined

all other RTL has no ambiguity .. the result of a snippet of code results in known values

What about 99% of all codes using if then else or case statements or while loops? Is that not a state machine then?

and in this case the user asked (in 2018) about why us_4_5_en" is the signal  that is "high" even though it should be low 

 

Well his code has lots undefined and that are all undefined signals arent they?

 

Second 

 

I appreciate what you write on using constraints and the simulation tools

but the point im making is that the simulation is less safe than the real world experiment so I wrote

a good way to check is to see if the behavior is same at -40 degrees and 150 degree Celsius

I know the chip was build for those temperatures - the point is what about your design?

If I have a design using the limits of the setup and hold boundaries at normal temperature

it will fail when one pushes the temperatures - and it is realistic to test of one has the right leaway in the timing under those extreme temperatures is all I said

 

Third

 

I appreciate you telling me how the Chipscope works basically one can do it yourself by simply gathering the signals in real time inside the BRAM's

But the Chipscope makes it easier because one does not need to programm that interface  - Xilinx does offer really useful tools I must concede and is trying to help a lot

 

 

sorry for bringing my precisions and insisting on them I just am pretty sure that many here that dont spend hours with the FPGA and simply tell things are costing others hours and hours of wasted time

FPGA design is all about thinking logically in a way that synthesizes well - the mind plays tricks and one often omits things thats why simulation's are helpful but ultimately only uncover the RTL errors

For synthesizing errors I used to use tools like Synplicity that go beyond and look at the far more

There are people having their rule books to code

 

I stick to one style that works and I re use the same all over and I actually use javascript to code my HDL because why waste time to code all by hand?

here a tool I wrote to autoprogram verilog HDL you can modify it for VHDL or anything

please save the following code as example.html and open it in a browser

or use the file SLURBgeneral.html I provided as attachment

Spoiler

<!DOCTYPE html>
<html>
<body>
<p id="demo"></p>
<script>
console.log(" type=\"text/javascript\" ");
console.log(" Digital Xlyns Inc. All rights reserved");
console.log(" Troendle(Javascript tutorial how to autocode HDL) ");
console.log(" Work is for free and donated to anyone wanting to use FPGA's");
console.log(etad);
// type="text/javascript"
// Digital Xlyns Inc. All rights reserved
// Summer 2019 Mercer Island, WA
// Troendle(Javascript)
// Work is for free and donated to anyone wanting to use FPGA's
// Sun Sep 29 2019 2:01:00 PM GMT-0700 (Pacific Daylight Time)

var etad = new Date();
var i;
var j;

var scale = 7; // i : y-axis
var depth = 0; // j : x-axis

var text = "`timescale 1ns / 1ps<br>";

text += "// <b>HDL"+scale+"00"+depth+"</b> scale:"+scale+" and depth "+depth+" <br><br>";
text += "// " + etad + " <br>";
text += "// Automatic Code Generation<br>";
text += "// Digital Xlyns Inc., WA <br>";
text += "// Author: Peter-Paul Troende<br>";
text += "// All rights reserved <br>";
text += "// Anyone is welcome to ask questions or to join as volunteer: digital@xlyns.com <br><br>";

text += "<br>module example( clk, led["+scale+" :"+depth+"] );";
text += "<br> &nbsp &nbsp output [7:0] led;";
text += "<br> &nbsp &nbsp input clk; <br>";
text += "<br>";
text += "reg [7:0] ledx; <br>";
text += "<br>";
text += "always @(posedge clk)<br>";
text += "&nbsp begin<br>";
text += "&nbsp &nbsp ledx["+scale+" :"+depth+"] <= ledx["+scale+" :"+depth+"] + 1; <br>";
text += "&nbsp end<br>";
text += "<br>";
text += "assign led[7:0]= ledx[7:0]; <br>";

for (j = 0; j < (scale); j += 1) {
text += "//wire [7:0] example"+scale+"_"+j+";"+ "<br>";
}

text += "<br><br>";

text += "<br>endmodule ";

document.getElementById("demo").innerHTML = text;

// here some more usefull functions
function dec2bin(dec) {
return dec.toString(2);
}

function padDigits(number, digits) {
return Array(Math.max(digits - String(dec2bin(number)).length + 1, 0)).join(0) + dec2bin(number);
}

function getRandomInt(max) {
return Math.floor(Math.random() * Math.floor(max));
}

// to grab any bits using javascript one use .substr(xxx.length)
// to learn or have questions in javascript
// https://www.w3schools.com/

</script>
</body>

</html>

0 Kudos
drjohnsmith
Teacher
Teacher
798 Views
Registered: ‎07-09-2009

Hi

reading your posts here,

   I must dis agree with most you say

  the idea of centre clocking a bram so that it gathers better signals, is just not the way the toos work

    The idea of over tempraturing a chip gives a better idea as to how well it can work over temperature is just wrong,

        I was always taught a random sample of one is not a sample but a hope.

The tools and constraints are the one way of guaranteeing your design meets timing over all PVT

Writing anything else to then generate VHDL, particularly something simple as you demonstrate just sounds like more work,

    why you would want to stretch jave script , which is inherently a single process system and has no idea of clocks, to write VHDL / Verilog which inherently parallel and clock aware, sounds strange.

Yes i use code to write out ROMs for us, but as a general tool !!

Sorry

Thats my view,

   Im very happy its a free world and you can express yours, but I just don't think we can agree on this, 

 

<== If this was helpful, please feel free to give Kudos, and close if it answers your question ==>
xlyns
Adventurer
Adventurer
778 Views
Registered: ‎01-09-2018

A Chipscope

avrum wrote:

The capture is exactly as you describe for your mechanism - while the clocks are running, the data is written synchronously and at full speed to BRAMs allocated to the ILA.

In other words it was my fault when I asserted that Chipsciope did it wrong the method I described is seemingly exaclty the way Chipscope is done - that is good so were on the same page

but your disagreing with avrum and told the tool works differently - could you explain how then chipscope does the real time capture if not with the BRAM?

 

B Testing Timing with Temperature

the transistors are affected:

https://en.wikipedia.org/wiki/Threshold_voltage look under body effect temperature dependance (Bolzman constant x Temperature kT)

the tracks current is affected because the speed if an edge is i = C x dV/dT there too you have the Temperature delta that is critical because

its different if cold than very hot environment, so even if the simulation can calculate a very good approximation the real life is more precise

(just look at the equations for the treshold voltage S. M. Sze, Physics of Semiconductor Devices, Second Edition, New York: Wiley and Sons, 1981, pp. 496–504. 

and imagine for every transistor all the equations are needed but the simulation tool can impossibly do that in time so its the best approximation we get

anyone correct me if im wrong here)

You can try the simulation over temperature but you got to generate the .ba file and it will show that the timing is very different on temperature

 

C Javascript

 

You might want not to write one module in RTL but structural logic gate per logic gate to reproduce accurately an electronic circuit and if its a complexe circuit you can try type all by hand?

If you open with the browser the SLURBgeneral.html (sorry for the name) it shows the code you can then copy paste 

If you open with a notepad you see the javascript and html that is easy to modify 

all to say don't code fancy just re use always the simple HDL constructs and the javascript makes it easy to have 20 pages of code you can then modify in an aye blink

and has no typo errors so the design is faster trust me 

 

D political views

you wrote:  I'm very happy its a free world

May I suggest you follow the consensus of being neutral, avoiding politics,

this discussion is about microelectronics and helping people spend less time for greater results with the amazing FPGA's

PS:

just as comment when you say you are very happy to be free it is from the logical standpoint not making much sense,

of course one is happy to be happy or happy to be free or less hungry when one eats, its the same as one is elevating when going up the stairs?

0 Kudos
avrumw
Guide
Guide
763 Views
Registered: ‎01-23-2009

all other RTL has no ambiguity .. the result of a snippet of code results in known values

What about 99% of all codes using if then else or case statements or while loops?

Look, I really don't like contradicting people in the forum. But you are saying here is simply incorrect, and I am worried that it will lead others to mistrust the synthesis tool and/or code in an inefficient manner.

There is nothing imprecise about if/then/else or case or loop statements. When used the right way (i.e. in a way that doesn't infer latches) the results are completely deterministic - the tools have no freedom to set values to unknown or unspecified values.

always @(posedge clk)
begin
  if (enable)
     q <= d;
end

This is an else-less if. It is 100% legal, 100% recommended and 100% unambiguous. Any belief that it is otherwise is just incorrect.

I go back to my original statements on this topic. Unless your coding is wrong, which will result in either syntax errors or unintended latch generation (which shows up as a warning), having variables that are only given values in some branches of if/case statements (or even on certain iterations of loops) does NOT result in unpredictable synthesis behavior, or variables that have unknown/undefined values.

As for what the original poster (who has apparently long abandoned this thread) observed (an apparent incorrect value on a signal as observed by the ILA) - this is caused by something else; a misconnected ILA signal, a misinterpretation of the code, a misinterpretation of the observation, or any of a number of other reasons. But NOT simply due to the fact that the coding style uses elseless if.

Avrum

xlyns
Adventurer
Adventurer
749 Views
Registered: ‎01-09-2018

From what I gather, programming is about what one wants to be done in assembler without taking the extend of all coding by hand, so most of the time it is a guesswork how the compiler/interpreters will go

Synthesis is pretty similar we often code guessing - but the difference is the compilers/interpreters in the software world are pretty simple to guess in comparison with the almost infinit sea of possibilities in the FPGA (just look at the timing if there is one edge lag - and that I did experience from one synthesis tool to another version one)

Xilinx synthesis tools change year by year - what you guess with ISE6.2 wont be the same as ISE9 or Vivado2019 and so on - it is misfortunately not as easy as the processors becausewe virtually can have anything going on, so this is a critical ground

"us_4_5_en" is the signal that is "high" is what the poster initially wrote even if it was expected "low" in fact the screenshots show its toggling was my feeling - so we see that its not me inventing the issue its the core of this post

the point to be a good FPGA designer is to guess what the team in the synthesis development have decided - that is practically impossible specially when one considers that they always change people and even outsourced the design team to Asia where it was then no wonder that the Vivado was different than the initial ISE - im not saying better or worse but just different.

In all those differences people have one is better off to simply stick to pure logical thought all the rest is speculation

your example clock event         if ( EN ) Q<=D;  is best implemented with a D FF with enabler pin and that is why everyone knows it is synthesised as  if ( EN ) Q<=D; else Q<=Q;

But earlier this month you wrote (avrum 2-6-2021) 

If the signal is assigned a value before the if/case statements - this is the default. Unless overridden by one of the if/case clauses, the value will be the default

the way you where seeing it would not result in the inference of a D FF because  if ( EN ) Q<=D; else Q<=0;  for a default to 0 ????

 

Like wise programmers are mocked somtimes because of the sheer trial and error they have to do

the FPGA designers are on this path I think wasting considerable time guessing what the synthesis team was thinking in the season?

 

In fact I would wish everyone would unanimously agree to the top down approach and that means that before even doing any compromises or fixes one should simply 

think in pure logical terms and in my eyes the  if ( EN ) Q<=D;  should formally be synthesised as a mux to the D FF input

and the mux NOT ( EN ) input should be aswell 0 or 1 or Q or anything in the world just to teach the user that if he wants something he got to describe exactly what he wants

but I must admit that then the best optimisation would be to choose Q as default and hence use a D FF with enable pin.

0 Kudos