T
Trygve Laugstøl
Guest
On 1/24/11 10:30 PM, Paul Uiterlinden wrote:
--
Trygve
No, it fails with the error message in the subject.
--
Trygve
Navigation
Install the app
How to install the app on iOS
Follow along with the video below to see how to install our site as a web app on your home screen.
Note: This feature may not be available in some browsers.
More options
You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an alternative browser.
You should upgrade or use an alternative browser.
N
Nicolas Matringe
Guest
Le 24/01/2011 20:51, rickman a écrit :
(and now I'll stay out of the discussion but will keep watching with
great interest since I happen to be French)
Nicolas
Thanks Rick. Working late nights happens sometimes, though.This is probably a discussion to stay out of, but I want to correct a
misapprehension on your part. I have worked with the French at a
major telecom company and will tell you that they are no more
incompetent or drunk than American workers. The continent does have a
different work culture in terms of leave. They get lots more vacation
than we typically do and they manage to get their work done without
working late nights and weekends.
(and now I'll stay out of the discussion but will keep watching with
great interest since I happen to be French)
Nicolas
C
comp arch
Guest
On Jan 24, 3:09 am, David Brown <da...@westcontrol.removethisbit.com>
wrote:
strongly.
So the customers have been listened to, but I guess you can't turn an
tanker on a dime, and you can't replace massively complex software
overnight, but the next generation is coming...if you have a Xilinx
FAE, ask them!
wrote:
I've been told by many a FAE that the SW is being addressed veryOn 23/01/2011 06:10, John Larkin wrote:
On Sat, 22 Jan 2011 23:03:16 -0600, "k...@att.bizzzzzzzzzzzz"
k...@att.bizzzzzzzzzzzz> wrote:
On Sat, 22 Jan 2011 18:20:55 -0800, John Larkin
jjlar...@highNOTlandTHIStechnologyPART.com> wrote:
http://www.eetimes.com/electronics-news/4212400/Xilinx-to-shutter-Fre....
Yikes, this explains some stuff. I wonder how long it will take to
undo the damage.
Damage? The damage caused by closing a software development lab?
I meant the damage likely *done* by that lab. We'd been speculating
how Xininx managed to snarl up their software so thoroughly, and
whether they will ever get it fixed. I can't imagine why they'd
outsource something this important to France.
I find it hard to believe that supposedly educated, intelligent and
experienced engineers can post such ignorant xenophobic drivel.
Xilinx (or rather, their users and customers) have trouble with the
Xilinx software because the Xilinx leadership do not prioritise it
appropriately, and (apparently) do not listen to or understand the
issues customers have with the software. They alone are at fault. It
could well be that the main management fault was to hire a development
team that was not competent to do the development - but the problem is
their lack of competence, not their nationality!
I know that sci.electronics.design is a hangout for mostly geriatric
American right-wingers who like to spend their free time blaming the
world's ills on "leftist weenies", foreigners, atheists, intellectuals,
and other dangerous sub-humans. That's fair enough, within the limits
of freedom of speech. It can even be entertaining at times. But please
keep that sort of thing within s.e.d. and not serious newsgroups.
Follow-up flames to s.e.d., and leave c.a.f. alone for a possible
discussion about the actual effect of this news on Xilinx and its customers.
strongly.
So the customers have been listened to, but I guess you can't turn an
tanker on a dime, and you can't replace massively complex software
overnight, but the next generation is coming...if you have a Xilinx
FAE, ask them!
R
RCIngham
Guest
STATE_M_1Seems to be a problem of MUX extraction but only with AREA optimizatio
set in synthesis options
the code is long as hell... more than 1400 codelines But here you are a
example of what i do with a variable in a state of the state machin
read_meas stateread_meas is a state, synchronous with clock, i and j are variabl
declared in the process. i is always 1 when the machine comes in th
when read_meas => -- STOP condition already managed in each step before
j := 0; -- important for latency
wr_en_0 <= '0'; -- disable writing in fifo
if i = 1 then -- i is 1 only at the first read of measurement
meas.coar_t <= indata_meas_in(24 downto 17);
meas.fine_t <= indata_meas_in(16 downto 0);
rd_en_meas <= '0'; -- don't read anymore
i := 2;
state_m_1 <= fill;
else -- if i is not 1 (should be 2) the machine save data
meas.coar_t <= indata_meas_in(24 downto 17);
meas.fine_t <= indata_meas_in(16 downto 0);
rd_en_meas <= '0'; -- don't read anymore
state_m_1 <= check; -- data are ready to be checked in oputput
end if;
-------------
Is that the process that cause the Packing error?
Post the whole of that process, with the signal definitions that ar
relevant,
and the package use declarations.
As a rule of thumb, if your processes are > 100 lines long, they are to
big for maintainability.
---------------------------------------
Posted through http://www.FPGARelated.com
E
Emanuele83
Guest
Seems to be a problem of MUX extraction but only with AREA optimization set in synthesis options
the code is long as hell... more than 1400 codelines But here you are an example of what i do with a variable in a state of the state machine STATE_M_1
read_meas is a state, synchronous with clock, i and j are variable declared in the process. i is always 1 when the machine comes in the read_meas state
when read_meas => -- STOP condition already managed in each step before
j := 0; -- important for latency
wr_en_0 <= '0'; -- disable writing in fifo
if i = 1 then -- i is 1 only at the first read of measurement
meas.coar_t <= indata_meas_in(24 downto 17);
meas.fine_t <= indata_meas_in(16 downto 0);
rd_en_meas <= '0'; -- don't read anymore
i := 2;
state_m_1 <= fill;
else -- if i is not 1 (should be 2) the machine save data
meas.coar_t <= indata_meas_in(24 downto 17);
meas.fine_t <= indata_meas_in(16 downto 0);
rd_en_meas <= '0'; -- don't read anymore
state_m_1 <= check; -- data are ready to be checked in oputput
end if;
-------------
the code is long as hell... more than 1400 codelines But here you are an example of what i do with a variable in a state of the state machine STATE_M_1
read_meas is a state, synchronous with clock, i and j are variable declared in the process. i is always 1 when the machine comes in the read_meas state
when read_meas => -- STOP condition already managed in each step before
j := 0; -- important for latency
wr_en_0 <= '0'; -- disable writing in fifo
if i = 1 then -- i is 1 only at the first read of measurement
meas.coar_t <= indata_meas_in(24 downto 17);
meas.fine_t <= indata_meas_in(16 downto 0);
rd_en_meas <= '0'; -- don't read anymore
i := 2;
state_m_1 <= fill;
else -- if i is not 1 (should be 2) the machine save data
meas.coar_t <= indata_meas_in(24 downto 17);
meas.fine_t <= indata_meas_in(16 downto 0);
rd_en_meas <= '0'; -- don't read anymore
state_m_1 <= check; -- data are ready to be checked in oputput
end if;
-------------
E
Emanuele83
Guest
Yes it cause the packing error, but not always...
WHAT??? 100 lines? What do you mean with maintainability?
My process has more than 900 lines... Sorry, but how can I separate a process in so small packages and do not go crazy with latency, synchronization and so on?
I wold implement the whole design in schematics, it will be much easier...
WHAT??? 100 lines? What do you mean with maintainability?
My process has more than 900 lines... Sorry, but how can I separate a process in so small packages and do not go crazy with latency, synchronization and so on?
I wold implement the whole design in schematics, it will be much easier...
R
RCIngham
Guest
http://www.google.co.uk/search?q=what+is+maintainabilityYes it cause the packing error, but not always...
WHAT??? 100 lines? What do you mean with maintainability?
synchronization and so on?My process has more than 900 lines... Sorry, but how can I separate
process in so small packages and do not go crazy with latency
I spent many months trying to verify another engineer's PCI Bridge. HiI wold implement the whole design in schematics, it will be muc
easier...
'style' included all-in-one processes several hundred lines long. Most o
the time when he corrected a bug that I found he stuck a different one in
And that was in RTL simulation, not post-P&R, or on the hardware!
Perhaps you need to envisage the hardware implementation that you ar
trying to achieve a little more deeply. Split it into counters, muxes
adders, pipelining stages, and so on. But it's up to you, it's your job o
the line. Do whatever you need to get your design working at the require
speed...
---------------------------------------
Posted through http://www.FPGARelated.com
R
rickman
Guest
On Jan 26, 10:16 am, Emanuele83 <emanuele83katam...@googlemail.com>
wrote:
I'm with Robert on this one. If your code is so large that you can't
explain it to us, it will be much harder for you to analyze. The code
snippet that you posted is too small to see if you are using the
variables correctly. You test I and then assign it another value, but
it isn't checked again. A variable should be assigned a value before
it is used no matter how the code is executed, or it describes a
register and adds the latency you are trying to avoid.
I keep my entire modules to around 150 to 200 lines if I can.
Processes are typically 10 to 50 lines. State machines can be much
larger of course, but you can try to put as much as possible outside
the big case statement process to minimize the complexity. Think of
the state machine as the sequencer of a CPU. Then do all the logic
for controls separately. This can help eliminate latency too as the
control decode can be done with combinatorial logic eliminating the
registers that cause latency.
Like Robert suggests, I always start with some sort of diagram showing
where the registers go and then describe that in my HDL. Then I flesh
it out with the various control logic.
Rick
wrote:
Yes it cause the packing error, but not always...
WHAT??? 100 lines? What do you mean with maintainability?
My process has more than 900 lines... Sorry, but how can I separate a process in so small packages and do not go crazy with latency, synchronization and so on?
I wold implement the whole design in schematics, it will be much easier....
I'm with Robert on this one. If your code is so large that you can't
explain it to us, it will be much harder for you to analyze. The code
snippet that you posted is too small to see if you are using the
variables correctly. You test I and then assign it another value, but
it isn't checked again. A variable should be assigned a value before
it is used no matter how the code is executed, or it describes a
register and adds the latency you are trying to avoid.
I keep my entire modules to around 150 to 200 lines if I can.
Processes are typically 10 to 50 lines. State machines can be much
larger of course, but you can try to put as much as possible outside
the big case statement process to minimize the complexity. Think of
the state machine as the sequencer of a CPU. Then do all the logic
for controls separately. This can help eliminate latency too as the
control decode can be done with combinatorial logic eliminating the
registers that cause latency.
Like Robert suggests, I always start with some sort of diagram showing
where the registers go and then describe that in my HDL. Then I flesh
it out with the various control logic.
Rick
E
Emanuele83
Guest
from the Wikipedia's definition of Maintainability in Engineering:
In engineering, maintainability is the ease with which a product can be maintained in order to:
_correct defects
_meet new requirements
_make future maintenance easier, or
_cope with a changed environment
I think that in my case the "cope with" sentence is important:
_the code works in post synthesis simulation
_suppose that the requirements are fixed: I do not want to optimize it but only to let it work in REAL logic
_suppose that I do not care for the future
_In this case if the environment means a different board, a different FPGA, a different temperature, I do apologise, but the damned programming, compiling tool, must be able to synthetise, compile, translate, MAP and PAR my design in the worst case. So if the design timing constraints are met, if there are no errors I suppose that the LOGIC must implement my FW. I do agree that there are better or worse HDL techniques, but since the user interface does not show a red ERROR, I expect that if I compile the same FW with AREA or SPEED optimization (seeing the same, reasonable, constraints are met), I expect that the real FPGA board work.
If I have a report that I cannot trust, why create the report itself? Why give a synthesis tool which do not work as expected if the information which gives (the reports, the warnings, the error, the programming bitstream) are not real, or do not work as expected?
If I am wrong, please explain me the way to understand how the FPGA designing works.
Emanuele
In engineering, maintainability is the ease with which a product can be maintained in order to:
_correct defects
_meet new requirements
_make future maintenance easier, or
_cope with a changed environment
I think that in my case the "cope with" sentence is important:
_the code works in post synthesis simulation
_suppose that the requirements are fixed: I do not want to optimize it but only to let it work in REAL logic
_suppose that I do not care for the future
_In this case if the environment means a different board, a different FPGA, a different temperature, I do apologise, but the damned programming, compiling tool, must be able to synthetise, compile, translate, MAP and PAR my design in the worst case. So if the design timing constraints are met, if there are no errors I suppose that the LOGIC must implement my FW. I do agree that there are better or worse HDL techniques, but since the user interface does not show a red ERROR, I expect that if I compile the same FW with AREA or SPEED optimization (seeing the same, reasonable, constraints are met), I expect that the real FPGA board work.
If I have a report that I cannot trust, why create the report itself? Why give a synthesis tool which do not work as expected if the information which gives (the reports, the warnings, the error, the programming bitstream) are not real, or do not work as expected?
If I am wrong, please explain me the way to understand how the FPGA designing works.
Emanuele
N
Nico Coesel
Guest
Emanuele83 <emanuele83katamail@googlemail.com> wrote:
do.
In your original post you mention that communication between FPGAs is
not working. This raises my suspision that the delays between input to
FF and FF to output are not constrained. Check that first.
http://www.xilinx.com/itp/xilinx10/isehelp/dec_c_unconst_path.htm
Designing with FPGAs is not only a matter of writing correct HDL code.
Depending on how much you are pushing the speed limits there may be a
substantial amount of work in creating the constraints.
--
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
nico@nctdevpuntnl (punt=.)
--------------------------------------------------------------
In general computers do what they are told not what you expect them tofrom the Wikipedia's definition of Maintainability in Engineering:
In engineering, maintainability is the ease with which a product can be mai=
ntained in order to:
_correct defects
_meet new requirements
_make future maintenance easier, or
_cope with a changed environment
I think that in my case the "cope with" sentence is important:=20
_the code works in post synthesis simulation
_suppose that the requirements are fixed: I do not want to optimize it but =
only to let it work in REAL logic
_suppose that I do not care for the future
_In this case if the environment means a different board, a different FPGA,=
a different temperature, I do apologise, but the damned programming, compi=
ling tool, must be able to synthetise, compile, translate, MAP and PAR my d=
esign in the worst case. So if the design timing constraints are met, if th=
ere are no errors I suppose that the LOGIC must implement my FW. I do agree=
that there are better or worse HDL techniques, but since the user interfac=
e does not show a red ERROR, I expect that if I compile the same FW with AR=
EA or SPEED optimization (seeing the same, reasonable, constraints are met)=
, I expect that the real FPGA board work.
If I have a report that I cannot trust, why create the report itself? Why g=
ive a synthesis tool which do not work as expected if the information which=
gives (the reports, the warnings, the error, the programming bitstream) ar=
e not real, or do not work as expected?
If I am wrong, please explain me the way to understand how the FPGA designi=
ng works.
do.
In your original post you mention that communication between FPGAs is
not working. This raises my suspision that the delays between input to
FF and FF to output are not constrained. Check that first.
http://www.xilinx.com/itp/xilinx10/isehelp/dec_c_unconst_path.htm
Designing with FPGAs is not only a matter of writing correct HDL code.
Depending on how much you are pushing the speed limits there may be a
substantial amount of work in creating the constraints.
--
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
nico@nctdevpuntnl (punt=.)
--------------------------------------------------------------
E
Emanuele83
Guest
all the I/Os are constrained.
the point is:
same VHDL code+same constrains --> changing synthesis/mapping/PAR options --> CONSTRAINTS ALWAYS MET @40MHz --> the behaviour changes.
the point is:
same VHDL code+same constrains --> changing synthesis/mapping/PAR options --> CONSTRAINTS ALWAYS MET @40MHz --> the behaviour changes.
Exactly what I do with my code that has been simulated and the algorithm results correct.In general computers do what they are told not what you expect them to
do.
N
Nico Coesel
Guest
Emanuele83 <emanuele83katamail@googlemail.com> wrote:
40MHz you must constrain the input to FF and FF to output paths as
well!
--
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
nico@nctdevpuntnl (punt=.)
--------------------------------------------------------------
Read what I'm typing: clock constraints are not enough for designs atall the I/Os are constrained.
the point is:
same VHDL code+same constrains --> changing synthesis/mapping/PAR options --> CONSTRAINTS ALWAYS MET @40MHz --> the behaviour changes.
40MHz you must constrain the input to FF and FF to output paths as
well!
--
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
nico@nctdevpuntnl (punt=.)
--------------------------------------------------------------
R
rickman
Guest
On Jan 27, 7:42 am, Emanuele83 <emanuele83katam...@googlemail.com>
wrote:
synthesis designs.
My recommendation is to narrow your focus and problem range. You can
focus on one of your problems and figure out what is wrong which may
solve all the problems. Or perhaps cut out specific sections of your
design and test that separately. Maybe design some specific logic to
test your hardware since you can't say that is definitely working.
This is the stuff that separates the men from the boys...
Instead of complaining about the process, you need to learn the
process and work with it. No, it is far from perfect and never really
easy. But if it were easy, anyone could do it and they would hire out
of work interior decorators instead of engineers!
Rick
wrote:
There is a big difference between working simulation and workingall the I/Os are constrained.
the point is:
same VHDL code+same constrains --> changing synthesis/mapping/PAR options --> CONSTRAINTS ALWAYS MET @40MHz --> the behaviour changes.
In general computers do what they are told not what you expect them to
do.
Exactly what I do with my code that has been simulated and the algorithm results correct.
synthesis designs.
My recommendation is to narrow your focus and problem range. You can
focus on one of your problems and figure out what is wrong which may
solve all the problems. Or perhaps cut out specific sections of your
design and test that separately. Maybe design some specific logic to
test your hardware since you can't say that is definitely working.
This is the stuff that separates the men from the boys...
Instead of complaining about the process, you need to learn the
process and work with it. No, it is far from perfect and never really
easy. But if it were easy, anyone could do it and they would hire out
of work interior decorators instead of engineers!
Rick
J
Jay
Guest
Pratap <pratap.iisc@gmail.com> wrote:
I've used in the past.
tool to create location constraints. This is a quick and dirty way thatHi,
I am using Xilinx Virtex II Pro device to generate some programmable
delays which can be as close to each other as possible with good
linearity between the delays obtained against the input setting. For
each increment in the input setting, the delay blocks are designed
such that the return path of the signal is delayed by two MUX and two
inverters each time. Each of my delay block contains one inverter in
upper path and closes the loop to the previous stage with one
inverters and and one MUX in its feedback stage. The following picture
illustrates that.
http://picasaweb.google.com/pratap.iisc/Pravas#5567043899536627202
Now the problem I am facing is that, when i do the P&R of the circuit
of 10 stages, it places the individual delay stages all around the
FPGA board resulting in huge delays between adjacent digital control
codes along with non-linearity in the out put delays. If I could some
how instruct the tool to place the delay cells(I feel each of them
being so small can be fit into a single slice) adjacent to each other
in slice level I hope to get lesser delay and better linearity. Can
anybody help me with how exactly to go about it?
I saw some options like RLOC which can help in placing a single net
into a particular slice in FPGA. But am not sure whether it can help
me in placing all my ten delay element blocks adjacent to each other?
Hoping for some constructive solution,
Thanks in advance.
Pratap
Assuming you are using ISE, you can use the post synthesis floor planning
I've used in the past.
G
glen herrmannsfeldt
Guest
Pratap <pratap.iisc@gmail.com> wrote:
(snip)
You describe a block of CLBs and their connections. P&R places
the whole block, including the routes defined in the block, and
then routes to and from the block, as needed.
I don't know if newer tools support it, though.
-- glen
(snip)
There used to be an option called RPM, Relationally Placed Macros.Now the problem I am facing is that, when i do the P&R of the circuit
of 10 stages, it places the individual delay stages all around the
FPGA board resulting in huge delays between adjacent digital control
codes along with non-linearity in the out put delays. If I could some
how instruct the tool to place the delay cells(I feel each of them
being so small can be fit into a single slice) adjacent to each other
in slice level I hope to get lesser delay and better linearity. Can
anybody help me with how exactly to go about it?
You describe a block of CLBs and their connections. P&R places
the whole block, including the routes defined in the block, and
then routes to and from the block, as needed.
I don't know if newer tools support it, though.
-- glen
E
Emanuele83
Guest
I must constrain also the input FF, must I? Is it written in the holy bible?
why should I add other constraints to create confusion when the IO are already constrained with OFFSET I/O and in the unconstrained timing report there is no sign of one of this i/Os already constrained?
Suppose that I constrain each and every I/O FF and it does not work. which is the next advice? Try to constrain AREA of each block?
Xilinx says: constrain the design as less as possible, thus I think that add more constraints is the wrong way until I don't have figured out what the hell is going on here.
I will repeat to myself my questions, here, just to keep then in mind:
IF the period/offset constraint are MET, WHY should I constrain also the INPUT FF PATH?
WHY if I modify slightly the code, or the ISE properties, the system CHANGE BEHAVIOUR?
WHY in another projects (SPARTAN 2 SPARTAN 3A) my VHDL style of programming is working correctly WITHOUT ANY CONSTRAIN AT THE SAME CLOCK SPEED?
Best
Emanuele
why should I add other constraints to create confusion when the IO are already constrained with OFFSET I/O and in the unconstrained timing report there is no sign of one of this i/Os already constrained?
Suppose that I constrain each and every I/O FF and it does not work. which is the next advice? Try to constrain AREA of each block?
Xilinx says: constrain the design as less as possible, thus I think that add more constraints is the wrong way until I don't have figured out what the hell is going on here.
I will repeat to myself my questions, here, just to keep then in mind:
IF the period/offset constraint are MET, WHY should I constrain also the INPUT FF PATH?
WHY if I modify slightly the code, or the ISE properties, the system CHANGE BEHAVIOUR?
WHY in another projects (SPARTAN 2 SPARTAN 3A) my VHDL style of programming is working correctly WITHOUT ANY CONSTRAIN AT THE SAME CLOCK SPEED?
Best
Emanuele
R
rickman
Guest
On Jan 28, 3:07 am, Emanuele83 <emanuele83katam...@googlemail.com>
wrote:
There are many, many problems that can cause the symptoms you are
seeing. How do you know that it is not a hardware problem? You've
already found one hardware problem. How do you know it isn't a design
problem such as a bad clock domain crossing? Why are you so focused
on the idea that the tools are messing up your design?
So far I can't tell that you have tried any of my other advice.
Rick
wrote:
How do you know that your problem is a timing constraint problem?I must constrain also the input FF, must I? Is it written in the holy bible?
why should I add other constraints to create confusion when the IO are already constrained with OFFSET I/O and in the unconstrained timing report there is no sign of one of this i/Os already constrained?
Suppose that I constrain each and every I/O FF and it does not work. which is the next advice? Try to constrain AREA of each block?
Xilinx says: constrain the design as less as possible, thus I think that add more constraints is the wrong way until I don't have figured out what the hell is going on here.
I will repeat to myself my questions, here, just to keep then in mind:
IF the period/offset constraint are MET, WHY should I constrain also the INPUT FF PATH?
WHY if I modify slightly the code, or the ISE properties, the system CHANGE BEHAVIOUR?
WHY in another projects (SPARTAN 2 SPARTAN 3A) my VHDL style of programming is working correctly WITHOUT ANY CONSTRAIN AT THE SAME CLOCK SPEED?
Best
Emanuele
There are many, many problems that can cause the symptoms you are
seeing. How do you know that it is not a hardware problem? You've
already found one hardware problem. How do you know it isn't a design
problem such as a bad clock domain crossing? Why are you so focused
on the idea that the tools are messing up your design?
So far I can't tell that you have tried any of my other advice.
Rick
C
comp arch
Guest
On Jan 27, 7:42 am, Emanuele83 <emanuele83katam...@googlemail.com>
wrote:
sounds like you have), that the behaviour changes from run to run, and
that the reason is the implementation tool's fault.
It sounds like an asynchronous/clock domain issue. Do you have more
than one clock in the design? How are all crossings handled? Are any
of the external inputs/internal signals async to the clock at all?
As for process size - the tools themselves have no limitations in this
regard - other posters were only pointing out that for the engineer to
be able to keep a clear idea in his head, and to be able to quickly
visually verify that a process is correct, it helps to keep the code
split up into smaller more functional processes. It's not required,
but it makes the engineers life at design time, and for any later
modifications much easier. This is what was meant my maintainability.
Splitting a process up does not necessarily add latency - in fact, it
can help you discover and separate the more critical parts.
In a way it is like doing a schematic, it helps to know logically how
it should be separated in a schematic, and then code that.
good luck
wrote:
It is very unlikely that if you have constraints on the design (and itall the I/Os are constrained.
the point is:
same VHDL code+same constrains --> changing synthesis/mapping/PAR options --> CONSTRAINTS ALWAYS MET @40MHz --> the behaviour changes.
In general computers do what they are told not what you expect them to
do.
Exactly what I do with my code that has been simulated and the algorithm results correct.
sounds like you have), that the behaviour changes from run to run, and
that the reason is the implementation tool's fault.
It sounds like an asynchronous/clock domain issue. Do you have more
than one clock in the design? How are all crossings handled? Are any
of the external inputs/internal signals async to the clock at all?
As for process size - the tools themselves have no limitations in this
regard - other posters were only pointing out that for the engineer to
be able to keep a clear idea in his head, and to be able to quickly
visually verify that a process is correct, it helps to keep the code
split up into smaller more functional processes. It's not required,
but it makes the engineers life at design time, and for any later
modifications much easier. This is what was meant my maintainability.
Splitting a process up does not necessarily add latency - in fact, it
can help you discover and separate the more critical parts.
In a way it is like doing a schematic, it helps to know logically how
it should be separated in a schematic, and then code that.
good luck
E
Emanuele Carraro
Guest
Hello everybody,
I got on Friday a new board, with brand new FPGAs soldered rightly (it seems).
Now I test my non-working FW and the 3 boards that I have behaves equally, so I have only two possibility:
a_ the synthesis tool is failing, bu I tried the same FW on a different machine with a brand new copy of ISE 12.4 installed and it behaves the same in each and every board.
b_ my coding style is somehow wrong. I checked the Xilinx's seminar on the web at this address and I watched all the basic HDL and Spartan 3 FPGA specific seminars. Ok, my code is not perfectly written but not with huge errors (for example everything is synchronous the reset path is correctly done, but I use nested if and case that are not the right thing (this is what Xilinx says)
For example, the reset code pointed out by Mike here https://groups.google.com/d/msg/comp.arch.fpga/eQ5EeHECOQw/rO5YroyQhaUJ
is, in Xilinx's opinion, not the best choice.
Now I decided to rewrite the whole project following Xilinx's advices but before, please, focus on these two questions and only on these two:
1_ since I have constrained the clock period and offset in and out, with only one clock domain in the entire FPGA( in other words everything is clocked by the same source) and all the constraints are met must I trust the clock report? Even if the design does not behave as expected? I mean, with the same code and constraints, only changing a synthesis parameters (from AUTO to one-hot encoding, for example) the constraints are always met and the timing report does not show any setup/hold violation, how is it possible that the FPGA behaves differently, if not for a synthesis error/mistake or an HW failure?
2_ If this is normal: if, changing the code style, or the used resources, the behaviour changes even with all the constraints met, how am I supposed to use a debugger like CHIPSCOPE, which uses the internal FPGA resources? In other words, if introducing a CHIPSCOPE debugger the used resources change and subsequently is expected that the behaviour changes, how is possible to debug correctly?
Only doing errors is possible to learn, but without understanding them is not possible to learn at all.
Many thanks,
Emanuele
P.S. I am using the ISE tool for my projects, have you got advices for a different/surely-better tool for synthesis, translate, map and PAR with also a spread availability of IPs?
I got on Friday a new board, with brand new FPGAs soldered rightly (it seems).
Now I test my non-working FW and the 3 boards that I have behaves equally, so I have only two possibility:
a_ the synthesis tool is failing, bu I tried the same FW on a different machine with a brand new copy of ISE 12.4 installed and it behaves the same in each and every board.
b_ my coding style is somehow wrong. I checked the Xilinx's seminar on the web at this address and I watched all the basic HDL and Spartan 3 FPGA specific seminars. Ok, my code is not perfectly written but not with huge errors (for example everything is synchronous the reset path is correctly done, but I use nested if and case that are not the right thing (this is what Xilinx says)
For example, the reset code pointed out by Mike here https://groups.google.com/d/msg/comp.arch.fpga/eQ5EeHECOQw/rO5YroyQhaUJ
is, in Xilinx's opinion, not the best choice.
Now I decided to rewrite the whole project following Xilinx's advices but before, please, focus on these two questions and only on these two:
1_ since I have constrained the clock period and offset in and out, with only one clock domain in the entire FPGA( in other words everything is clocked by the same source) and all the constraints are met must I trust the clock report? Even if the design does not behave as expected? I mean, with the same code and constraints, only changing a synthesis parameters (from AUTO to one-hot encoding, for example) the constraints are always met and the timing report does not show any setup/hold violation, how is it possible that the FPGA behaves differently, if not for a synthesis error/mistake or an HW failure?
2_ If this is normal: if, changing the code style, or the used resources, the behaviour changes even with all the constraints met, how am I supposed to use a debugger like CHIPSCOPE, which uses the internal FPGA resources? In other words, if introducing a CHIPSCOPE debugger the used resources change and subsequently is expected that the behaviour changes, how is possible to debug correctly?
Only doing errors is possible to learn, but without understanding them is not possible to learn at all.
Many thanks,
Emanuele
P.S. I am using the ISE tool for my projects, have you got advices for a different/surely-better tool for synthesis, translate, map and PAR with also a spread availability of IPs?
C
comp arch
Guest
On Feb 2, 8:56 am, Emanuele Carraro
<emanuele83katam...@googlemail.com> wrote:
a) I really doubt the synth tool is producing incorrect logic. Imagine
the millions of different HDL projects that are synthesized, if there
was a fundamental RTL to logic translation flaw, it would be a big
deal. Just in case, it would be best to use all the default settings
on the synth tool (if you have changed them). The defaults would
naturally be what 99% of people use, so have had the most exercising
in reality.
b) This is possible too - It is still possible to use perfect syntax,
and style, but still write something that is somehow asynchronous, or
crosses clock domains incorrectly. Unfortunately coding guidelines can
never prevent those kinds of mistakes. Lint tools can help find some
structures that could cause trouble, as well as CDC tools (clock
domain crossing).
1) Having one clock domain simplifies things, as well as the fact that
you have constrained the inputs. but a few questions -
- do you use any PLL/DLL/MMCM logic. Have you ensured everything is
setup correctly here and any skews are being accounted for?
- in follow on to the above - you say there is one clock domain - but
is it actually the very same NET going to each piece of code, or are
there somehow different nets of the same frequency that are driving
different blocks. Because even though a clock may be the same
frequency, and come from the same source point - if there are not the
same net, there can be phase/skew differences that would have to be
handled carefully
- have you accounted for all inputs? are they all constrained? can
any of them glitch or be otherwise asynchronous?
- do you have proper reset synchonizers to release the reset?
2) Chipscope has helped me countless times, it really is a great tool.
I do see the dilemma here where you are concerned that adding it will
change the utilization, and as a result change the behavior again. So
the only suggestions i have here are:
- turn on design preservation. This should retain the synthesis and
placement/routing of unchanged parts of the design, and should fit
chipscope blocks into 'free' space. Of course some of the design may
have to be moved, but the tools do all they can to prevent that. If
the place and route are preserved, then so should design behaviour
- if inserting chipscope does cause the design to start functioning -
then I would keep iterating and making small tweaks until the design
is failing once more, but this time with chipscope in. Once you get
that, setting up chipscope to monitor the design won't affect its
running so you should be able to zero in on where the problem first
occurs.
- try to think up front how to partition your design so you can
determine what points to probe so failures can be detected by
chipscope.
As for alternative tools - on the synth side there are a number of
choices, but for map/par, I believe you have to use the ISE versions.
you could try plan-ahead, while it still uses the ISE tools under the
hood, it does allow you to easily floor-plan your design. It won't fix
this issue, but it should make working with / iterating / probing
signals with chipscope easier.
<emanuele83katam...@googlemail.com> wrote:
It is an interesting problem for sure. To answer your questions:Hello everybody,
I got on Friday a new board, with brand new FPGAs soldered rightly (it seems).
Now I test my non-working FW and the 3 boards that I have behaves equally, so I have only two possibility:
a_ the synthesis tool is failing, bu I tried the same FW on a different machine with a brand new copy of ISE 12.4 installed and it behaves the same in each and every board.
b_ my coding style is somehow wrong. I checked the Xilinx's seminar on the web at this address and I watched all the basic HDL and Spartan 3 FPGA specific seminars. Ok, my code is not perfectly written but not with huge errors (for example everything is synchronous the reset path is correctly done, but I use nested if and case that are not the right thing (this is what Xilinx says)
For example, the reset code pointed out by Mike herehttps://groups.google..com/d/msg/comp.arch.fpga/eQ5EeHECOQw/rO5YroyQhaUJ
is, in Xilinx's opinion, not the best choice.
Now I decided to rewrite the whole project following Xilinx's advices but before, please, focus on these two questions and only on these two:
1_ since I have constrained the clock period and offset in and out, with only one clock domain in the entire FPGA( in other words everything is clocked by the same source) and all the constraints are met must I trust the clock report? Even if the design does not behave as expected? I mean, with the same code and constraints, only changing a synthesis parameters (from AUTO to one-hot encoding, for example) the constraints are always met and the timing report does not show any setup/hold violation, how is it possible that the FPGA behaves differently, if not for a synthesis error/mistake or an HW failure?
2_ If this is normal: if, changing the code style, or the used resources, the behaviour changes even with all the constraints met, how am I supposed to use a debugger like CHIPSCOPE, which uses the internal FPGA resources? In other words, if introducing a CHIPSCOPE debugger the used resources change and subsequently is expected that the behaviour changes, how is possible to debug correctly?
Only doing errors is possible to learn, but without understanding them is not possible to learn at all.
Many thanks,
Emanuele
P.S. I am using the ISE tool for my projects, have you got advices for a different/surely-better tool for synthesis, translate, map and PAR with also a spread availability of IPs?
a) I really doubt the synth tool is producing incorrect logic. Imagine
the millions of different HDL projects that are synthesized, if there
was a fundamental RTL to logic translation flaw, it would be a big
deal. Just in case, it would be best to use all the default settings
on the synth tool (if you have changed them). The defaults would
naturally be what 99% of people use, so have had the most exercising
in reality.
b) This is possible too - It is still possible to use perfect syntax,
and style, but still write something that is somehow asynchronous, or
crosses clock domains incorrectly. Unfortunately coding guidelines can
never prevent those kinds of mistakes. Lint tools can help find some
structures that could cause trouble, as well as CDC tools (clock
domain crossing).
1) Having one clock domain simplifies things, as well as the fact that
you have constrained the inputs. but a few questions -
- do you use any PLL/DLL/MMCM logic. Have you ensured everything is
setup correctly here and any skews are being accounted for?
- in follow on to the above - you say there is one clock domain - but
is it actually the very same NET going to each piece of code, or are
there somehow different nets of the same frequency that are driving
different blocks. Because even though a clock may be the same
frequency, and come from the same source point - if there are not the
same net, there can be phase/skew differences that would have to be
handled carefully
- have you accounted for all inputs? are they all constrained? can
any of them glitch or be otherwise asynchronous?
- do you have proper reset synchonizers to release the reset?
2) Chipscope has helped me countless times, it really is a great tool.
I do see the dilemma here where you are concerned that adding it will
change the utilization, and as a result change the behavior again. So
the only suggestions i have here are:
- turn on design preservation. This should retain the synthesis and
placement/routing of unchanged parts of the design, and should fit
chipscope blocks into 'free' space. Of course some of the design may
have to be moved, but the tools do all they can to prevent that. If
the place and route are preserved, then so should design behaviour
- if inserting chipscope does cause the design to start functioning -
then I would keep iterating and making small tweaks until the design
is failing once more, but this time with chipscope in. Once you get
that, setting up chipscope to monitor the design won't affect its
running so you should be able to zero in on where the problem first
occurs.
- try to think up front how to partition your design so you can
determine what points to probe so failures can be detected by
chipscope.
As for alternative tools - on the synth side there are a number of
choices, but for map/par, I believe you have to use the ISE versions.
you could try plan-ahead, while it still uses the ISE tools under the
hood, it does allow you to easily floor-plan your design. It won't fix
this issue, but it should make working with / iterating / probing
signals with chipscope easier.