EDK : FSL macros defined by Xilinx are wrong

[Marco]

The warning talked about "3 NON-CLK pins" .. that's a dead giveaway for a
gated clock somewhere or using a signal which isn't a clock.... or using a
clock in a non-clock way. I would look at the circuit hard.

The clock divider has 2 outputs: a 50% duty cycle and a pulse at the last
count of counter.
I have connected 3 state machine to the pulse. Every machine and the other
block are faliing
edge sensitive.
I have made the counter and the comparator with core generator.

You might find a good option is to use a couple of SLR16's as counters for
your SPI. each can replace a number of 'loads' with a single one.

Seems a great idea, could you explain, please?

One solution is to duplicate the clock generator, the other is to ONLY use
the system clock. use a gate to latch the incoming data which is
generated
in parallel to the clock not from the clock.

I will try it as soon as possible.


Many and many thanks for your precious help.
Marco

 

[Marco]

"Marco" <marcotoschi@nospam.it> wrote in message
news:di2neu$gk3$1@news.ngi.it...

The warning talked about "3 NON-CLK pins" .. that's a dead giveaway for
a
gated clock somewhere or using a signal which isn't a clock.... or using
a
clock in a non-clock way. I would look at the circuit hard.


The clock divider has 2 outputs: a 50% duty cycle and a pulse at the last
count of counter.
I have connected 3 state machine to the pulse. Every machine and the other
block are faliing
edge sensitive.
I have made the counter and the comparator with core generator.


You might find a good option is to use a couple of SLR16's as counters
for
your SPI. each can replace a number of 'loads' with a single one.

Seems a great idea, could you explain, please?



One solution is to duplicate the clock generator, the other is to ONLY
use
the system clock. use a gate to latch the incoming data which is
generated
in parallel to the clock not from the clock.

I will try it as soon as possible.


Many and many thanks for your precious help.
Marco

I have finally found the trouble. I create a new thread to discuss on it.

Many Thanks
Marco

 

[J buytaert]

It seems to be a bit more suttle than that. In the data sheet mentioned is
stated on page 1:
"2.5 V/3.3 V Support with Individually Selectable Voltage and Slew Rate"

You can see in the revision history of the of the application note of the
I/O Features one can see that the 3.3/2.5 V I/O mixing was included in an
earlier version of the application note. Moreover, the knowledge database
describes how to implement it (which is what we tried and it doesn't work).
http://www.actel.com/kb/article.aspx?id=KI25851

And the macro library guide http://www.actel.com/documents/pa_libguide.pdf
states on e.g. page 62 which combinations of 2.5 and 3.3 V operation that is
supported.

Hence reading the documentation it is supported or at least has been
supported. The question we have is if someone knows a workaround, if the
feature has been supressed or knows why the Actel Designer compiler doen't
accept something that is described in the library guide.

 

[Phil Hays]

Philip Freidin wrote:

Oh yes it does! A two bit shift register is identical to a two
stage synchronizer.

For most purposes.

For physical floorplanning, it is not. If the UCF constrains two FFs
to a clb, and the FFs are in a SRL16, then build will fail.

For metastability, it is not. As I'm under the impression that SRL16s
FFs are slower, I suspect that they are not as metastable hard. Peter
or Austin, care to comment? If nothing else, there is not data on
SRL16s, so I can't be sure how good or bad the solution is. This is
also true of the BlockRAMs.

I should have mentioned this above, but I unchecked the box (shift
register extraction) so ISE didn't convert the FFs into a SRL16.

Probably better do cover this in the code. Add this line to the
Verilog:

// synthesis attribute shreg_extract of ss is no;


--
Phil Hays to reply solve: phil_hays at not(coldmail) dot com
If not cold then hot

 

[Neill A]

OK, I see why you were confused now. I've had a quick look, and I
actually have a copy of the app note which talks about mixed voltage
I/O, but it doesn't really say much more than you already seem to know.

Also after a quick check of the release notes for SP2, it seems this is
where the problem is:

Mixed mode I/O support has been removed from APA devices. As of SP2,
use of any of these mixed mode I/Os is prohibited: OB25XX, IOB25XX,
IOBL25XX, OTB25XX, OTBL25XX, or IB25XX. If any of these I/Os are
detected in an existing ADB, an error message appears, and alternative
non mixed-mode I/Os are suggested.

So I guess the solution would be to uninstall SP2.

 

[Kolja Sulimma]

timotoole@gmail.com wrote:

Firstly thank you very much for your detailed answer.

Is there ever scenario's where the area and switching overhead of a
systolic array would warrant a less bandwidth efficient, more serial
approach - or is that just plain ridulous to consider?
In fact only the serial solution has an area and switching overhead for
each computation. The systolic implementation only computes without
doing anything else. See below.

I'm not too sure what you mean by this? Surely there is an area
overhead for the systolic array versus a "serial"/single PE
implementation?

That's not efficiency, that's cost. Cost increases.

But for twice the area I get more than twice the speed for less
than twice the power. So the computations per area and the computations
per energy increase. That's what's called efficiency.

This is the great thing about systolic algorithms. There are many parallel
algorithms that are not systolic that get faster when adding more hardware
but at diminishing efficieny. For some problems only logarithmic speedup is
possible.

Using your example of an adder, I have a algorithm where it is possible
to avoid the addition completely if a certain condition occurs. With a
systolic array the addition has to be completed, Thus my question, of
whether a non- systolic implementation has major drawbacks.

Do not forget the cost of checking the condition. Even in serial CPUs a
branch is so expensive that doing a few extra operations can be more
desirable testing whether thy can be skipped.
[..]

More complicated are problems were the systolic algorithm requires more
operations than the serial algorithm. In that case you need to tradeoff
the gains per computation of the systolic implementation vs. the
improved number of computations of the serial algorithm.

I think this is my situation, so I'm going to try model the problem
with C and evaluate the operations & cycles for both approaches.

Also check what your performance requirement is. Expect the gain of an systolic
algorithm compared to operating serially on externall memory to be huge.
So if you waste 90% of the operations you are probably still faster.
*Deliberatly oversimplifing here*
But if a serial implementation meets your throughput target there is not much
adding hardware for more speed and efficiency.

You can try to run your C-model on a microblaze. This will be VERY inefficient,
but maybe it is fast enough ;-)

Kolja Sulimma

 

[Marie]

Thank you for your reply.
I do not find any .dcf file in my project directory.
The .sdc constraint file seems empty.
Could you tell me where I have to search?
And when I will found this file which name should I change?

Thank you very much,

Marie

 

[Kolja Sulimma]

Simon Heinzle wrote:

Hi everybody,

With ASICs, there are standard cell libraries in .lib file format for the
target process -- is there a comparable .lib file for the Xilinx FPGAs?

There are macro libraries but no standard cell libraries.
Subject tree based mappers do not work well for FPGAs and the timing models
used in ASIC flows don't either. Also, you do not need the geometrical
information contained in the library because you do not move cells around
or connect wires to them at specified locations. So there is no use for a
standard cell library with FPGAs.

FPGAs either use muxes as their basic elements (rare nowadays) in which case
BDD-based synthesis is the natural approach.
Or they use lookup tables that can implement any function with up to N inputs
(predominant architecture). In that case listing all possible functions in a
library isn't really helpful.


Kolja Sulimma

 

[Philip Freidin]

On Thu, 06 Oct 2005 08:05:57 -0700, Austin Lesea <austin@xilinx.com> wrote:

Phil,
I stand corrected,
Thanks.
It was late last night ...
Austin

Well it turns out I needed to be corrected by Phil Hays.
He is correct that if the shift register is mapped to an SRL16
then you can be in deep doo doo for constraints that expected FFs.

While making corrections to late night typing, please note that
in my posting, the following:

Both are correct. Paul's circuit is a shift register (2 bits) and
it is logically indistinguishable from a shift register.

should be:

"Both are correct. Paul's circuit is a shift register (2 bits) and
it is logically indistinguishable from a two stage synchronizer."


Since Phil Hays points out the mapping problem of a shift register
being mapped to the

"not as wonderful as real flip flops for building synchronizers"

SRL16s, then the 2 stage synchronizer, which are indestinguishable
from a 2 bit shift registers will also face this problem.

In my code I avoid all this by directly instantiating the FFs,
and then it is easy to attach placement constraints and timing
constraints.

In another posting by Phil Hays, he gives examples of such
constraints

INST "ss_1" LOC = "CLB_R1C1.S0" ;
INST "ss_0" LOC = "CLB_R1C1.S0" ;
or
INST "ss_1" RLOC = "R0C0.S0" ;
INST "ss_0" RLOC = "R0C0.S0" ;

INST "ss_1" TNM = "SYNC_FF";
INST "ss_0" TNM = "SYNC_FF";
TIMESPEC "TS_SYNCS" = FROM "SYNC_FF" TO "SYNC_FF" 2.5 ns;

Depending on the synthesizer, these can fail if it renames
the signals. Also these only work if they are at the top
of the hierarchy. Finding their correct name when the FFs
are inferred can be tricky, since changes elsewhere in your
code can cause the names to change. I believe that
instantiation is justified for the specific case of building
synchronizers.

Philip Freidin









===================
Philip Freidin
philip.freidin@fpga-faq.org
Host for WWW.FPGA-FAQ.ORG

 

[Kolja Sulimma]

Simon Heinzle wrote:

First of all, thanks for the reply!

Could these 'standard' libraries be used for timing analysis, e.g. for a
core gen normally used for ASICs (to get a rough but more meaningful timing
analysis than without any information)?

No.

But:
Your asic synthesis tool probably supplies a minimal example library.
(Our design compiler here for example has an AND-OR-NOT library with
only three cells)
You can generate the core from that and then export the resulting netlist
as VHDL.
Then you can add entities for the three cells and run the result through
WebPack. (Free download)
The result will be exact in the sense that the circuit really operates in
an FPGA at the resulting frequency. But of course your core generator
likely has made some design decisions that are really suboptimal for FPGAs.

Kolja Sulimma

 

Newman wrote:

aholt...@gmail.com wrote:
The Xilinx website isn't too clear with respect to the evaluation EDK
included with the Spartan-3 starter kit. Does anyone know if it is time
limited or feature limited? Can I run the reference microblaze designs
with it? Also, does anyone know if the starter kit will ship with
ISE/EDK 8.1i when it itself ships? Thanks!

cheers,
aaron

Aaron,
IIRC, the Spartan 3 Eval kit shipped with a 60 day eval EDK 6_3 back
in Feb 2005. It also came with a 60 day ISE6_3 eval. I have no
information what they ship now.

-Newman

Thanks. One other thing, do the discs come with the linux binaries as
well?

cheers,
aaron

 

[Ben Twijnstra]

Hi kedar,

I am doing some work targeted to StratixGX family for me RTL or gate
delay simulation is a must.

Can i do a post synthesis simulation in Modelsim for stratix GX Family
using the synthesis output design.vho file from QuartusII.
But this simulation should include gate delays specifically.

as like in Xilinx I can do a pre Map simulation which gives gate
delays.

Modelsim has the option to use a so-called SDF backannotation file to use
the gate (and wire) delays. Quartus generates the delay backannotation file
as <yourdesign>.sdo. For more info, look up SDF in the Modelsim manual.

Best regards,


Ben

 

[Paul Marciano]

A general question:

Synchronizers seem to be a basic building block, whether you have
external signals to sample or internal clock domains to cross. Yet to
use them seems to require careful constraint specification.

I wonder if it would make sense for there to be a language construct to
describe a sychronizer such that the tools would just do right
thing(TM) without having to get into these tricky details?

Or maybe for experienced engineer these details aren't tricky?

Regards,
Paul.

 

rafaelcns@gmail.com wrote:

Hello all,

I've recently been examining methods for acceleration of matrix
inversion... does anyone know of any hardware acceleration or
parallel processesing succesful method for matrix inversion?

Thanks for your help,

Rafael

I believe AccelChip has some IP for that; probably a VHDL generator...
www.accelchip.com

 

[morpheus]

Hey,
I have been dealing with this situation as well. When you compile the
design, look in the project folder under modelsim sub folder, you
should be able to find a .vo or .vho file depending upon your settings
for verilog or vhdl in quartus II.
Create a project in Modelsim and add the .vo or .vho file along with
the stratix GX atoms file, u should be able to get it from altera
website.
For gate delay simulation, get the .sdo file from the design's project
folder. When simulating in Modelsim, choose the SDO tab and add this
..sdo file there and then simulate...its MAGIC!!!
later
MORPHEUS

 

[Antti Lukats]

<jjohnson@cs.ucf.edu> schrieb im Newsbeitrag
news:1128647278.987068.51970@o13g2000cwo.googlegroups.com...

Summary: Should high-speed shift registers (purely DFFs) flow
left->right, top->bottom, or does it matter?

Doing a Virtex4 (LX100). I wound up with high-speed inputs (clocks and
serial data) on the IOBs that run vertically down the center of the
die. OK for clocks, since the DCMs and BUFGs are also in that center
column.

Regarding data: I deserialize the inputs, and pass parallel data to
some large datapath blocks that start on the left edge of the die. I
constrain all my deserializer logic to use sites near the center column
to minimize clock skew. (Sorry, I can't use the on-chip deserializers;
they max out at 10 bits, and I need 12.)

6 bit shift register places nicely into single CLB cluster with ALL routing
being implemente in the switchbox, eg with no local routing involved at all.
So there is no top to bottom or left to right issue at all as its so
compact. So as of shift register there is no issue.

but at 500MHz clock, sure careful design is required.

so for your deserializer

1) use idelay so you can fine adjust the routing delay/diff from iob to the
shift dff 'cluster'
1a) use DDR input flops in IOB for the first stage
2) place the parallel holding register 'around' the serializer cluster, this
could be possible with short local routing
2a) implement a 2 bit serial parallel cluster (that uses only swithcbox
routing) and place the 2 bit clusters so that they reach each by local
routing

you only need some RLOCs in your macros and all the thing is done.
sounds like fun thing todo - I was amazed myself when I measured actual real
clock speeds of 970MHz in slowest speed grade V4

Antti

 

[Neill A]

OK, I just assumed that you were using a dcf file since that is what
the error message reffered to. You could try reimporting your source
files into designer, but ensure the little tick box for keep exisiting
timing constraints is unticked. Then if it compiles you can then set
up your timing constraints again.

 

[Bill]

"Bob Perlman" <bobsrefusebin@hotmail.com> wrote in message
news:hidak117pd0s9icqp9ohofgjgcs8vq1ks4@4ax.com...

The problem with your approach is that the second flip-flop, the one
clocked with the 24 MHz falling edge, has less than half as much time
to settle (thanks to the AND gate delay) before being applied to the
circuit. If the first flip-flop says HIGH and the second flip-flop
says "I dunno," what happens to your circuit?

(first a modification) lets change this:

process(clk_24M)
begin
if rising_edge(clk_24M) then
if a = b then
q <= a;
end if;
end if;
end process;

to this instead:

process(clk_24M)
begin
if rising_edge(clk_24M) then
q <= a or b;
end if;
end process;

1.) At least one of the flip-flops are always correct.

2.) If one of the flip-flop outputs are metastable then the OR-gate says
1 or 0 (if one of it's inputs is metastabel).



And remember this can only happen around the rising or falling edge of the
1.8 MHz signal, so by doing this OR-thing we can get the correct bit-value
the first sample time or at the following sample time.



For my design it doesn't matter if I get the right bit-value shifted 1 more
clk in the 24 MHz clock domain.



I presume that the OR-gate always deliver a valid 0 (Vout<= VOL) or 1
(Vout=>VOH) when one of it's inputs is a valid 0 or 1 and the other is
undefined (between VIH and VIL). But i'm not sure of this behavior maybe
some one can reply on this?

 

[Bill]

"Bill" <billbill@telia.se> wrote in message
news:4346337d$0$49011$14726298@news.sunsite.dk...

I presume that the OR-gate always deliver a valid 0 (Vout<= VOL) or 1
(Vout=>VOH) when one of it's inputs is a valid 0 or 1 and the other is
undefined (between VIH and VIL). But i'm not sure of this behavior maybe
some one can reply on this?

What I mean is that I want to be sure that the OR-gate in the FPGA has the
following truth table:



A B | Q

----+---

0 X | 0 or 1

X 0 | 0 or 1

X 1 | 1

1 X | 1

1 1 | 1



(Where X means metastable, logical 0 or a logical 1)



Then my circuit will work.

 

[Sandro]

d...@xess.com wrote:

...
So the makefiles will work if these are still ASCII in 7.x
...

thanks a lot... I'll try it!

Sandro