EDK : FSL macros defined by Xilinx are wrong

[Hĺkon Lislebř]

Hi Austin,

Yes, you could make an edge detect which generates a reset pulse. I tried
it. But if the clock is lost the reset pulse will go away long before the
clock is back and then the DCM needs another reset. That reset will off
course come when CLK_LOS goes off, but I can not trust the CLK_LOS because
the open clk input picks up signal from another clock (BLVDS) and will often
indicate that a clock is present. An auto reset for my applications take som
FF's (shift register, delay to wait for lock signal after reset) and gates.
Multiply that with four DCM's and suddenly a small Virtex-II is gotten even
smaller. Off course you cannot cover all situations, and my telecom
application is a little bit demanding. It is just that an Auto-Lock would
have fit in so nicely! Yes, squeese that feature into the next -
Virtex-III?

Hakon


"Austin Lesea" <Austin.Lesea@xilinx.com> wrote in message
news:3F4A1E0C.47FC0DE4@xilinx.com...

Hakon,

How about an OR gate of the status bits indicating a failure to a flip
flop that genreates a one clock long reset pulse?

Lots of logic? three gates and a FF or two?

The 'Auto-Lock' suggestion is a good one. We will keep that in mind.

Austin

 

[Martin Thompson]

rickman <spamgoeshere4@yahoo.com> writes:

I am working with the ACEX 1K30 and I don't understand the structure of
the IOE. The diagram clearly shows three FFs; data input, data output
and output enable. The three FFs even have different types of
connections to the routing. But in the text, they seem to be saying
that there is only a single FF in the IOE.

Is there really only one FF in the IOE so that it can be either input or
output? Is the OE FF always in an LE rather than the IOE? Seems like
this would make for some trouble getting the timing in tight
situations.

Yeah - been there, done that - I had great fun making a 10KE do a 100MHz
SDRAM interface meet timing, due to the single flipflop :-( Someone once
described the 10KE datasheet to me as "less than totally transparent" or
some such.

The other gotcha is the implication that there is an asynch
preset on the FF - in the text it then describes that the P&R software
will automatically put an invertor fore and aft of the FF and use the
async reset input (that does exist). Making a bit of a hash of your
tco as a a result :-(

I was not a happy bunny that day, and from that day forward have made
a point of not looking at Altera's diagrams only reading the text...

Commiserations :-(

Martin

--
martin.j.thompson@trw.com
TRW Conekt, Solihull, UK
http://www.trw.com/conekt

 

[Alfredo]

Ray,
What I have in mind is mid complexity designs that would benefit from some sort
of automated flow to produce a better placement to fit into smaller or lower
speed grade devices, as the vendors promise.

I understand that most high end designers will be doing floorplanning and
constraining themselves, using on other tools, like formal verification, as they
make progress.

But what I would like to know is what are the features to look for in a 3rd
party floorplanner to make it worth it. If someone with average design
experience, wanted to use one of this tools to stitch IP/blocs or to make
modifications to other's designs (for an ECO, for example) what should I be
looking for?

I have also looked at hierarchical methodologies, but it only works if
implemented form the start. My testcases are large flat design that I've hacked.
I've found it difficult to partition these designs and make the changes to the
constraints to still meet timing. Most of these design had very narrow timing
margins and/or were almost full. For me, this is were one of these tool might
help. But I would appreciate input form this newsgroup.

Cheers,

***
Alfredo.


"Ray Andraka" <ray@andraka.com> wrote in message
news:3F4ABD12.60ECA6A1@andraka.com...

Says who? See http://www.andraka.com/gallery.htm for examples of large designs
that use placement constraints extensively. The key is to use hierarchy. In
order to do so with the current tools though, you'll have to do the placement
in
the bottom levels of your code, not in the floorplanner.

Anil Khanna wrote:

Using placement constraints is okay if you are trying to meet timing on
certain small sections of the designs AND you know if these are going to be
the bottleneck. It is not feasible to do this if you have a big design that
is using 90+% of the slices/LEs etc.


--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com

"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759

 

[Austin Lesea]

Hĺkon,

Well, sounds like you really do have a demanding application, and it therefore
it needs a well thought out and debugged solution. I would hate to try to match
our system design skills with yours (and get it wrong) so the cheapest and best
way to address thius is still using LUTs, SRL16s, and FFs.

And what are you using, a 2V40? We are still talking about less than a few
hundred CLB's, which is a tiny number in a 2V1000 or larger. If it is a 2V40,
or a 2V80, I can see your point, as it might get a bit crowded.

Is it possible to multiplex your clock quality logic among multiple DCMs? Sort
of a reset controller? Or use a picoBlaze to control all DCM resets? It is not
a function that needs the speed of the fabric, so one can replace it with
software, and a soft controller core like the picoBlaze. Might be an
advantageos trade-off.

Austin

"Hĺkon Lislebř" wrote:

Hi Austin,

Yes, you could make an edge detect which generates a reset pulse. I tried
it. But if the clock is lost the reset pulse will go away long before the
clock is back and then the DCM needs another reset. That reset will off
course come when CLK_LOS goes off, but I can not trust the CLK_LOS because
the open clk input picks up signal from another clock (BLVDS) and will often
indicate that a clock is present. An auto reset for my applications take som
FF's (shift register, delay to wait for lock signal after reset) and gates.
Multiply that with four DCM's and suddenly a small Virtex-II is gotten even
smaller. Off course you cannot cover all situations, and my telecom
application is a little bit demanding. It is just that an Auto-Lock would
have fit in so nicely! Yes, squeese that feature into the next -
Virtex-III?

Hakon

"Austin Lesea" <Austin.Lesea@xilinx.com> wrote in message
news:3F4A1E0C.47FC0DE4@xilinx.com...
Hakon,

How about an OR gate of the status bits indicating a failure to a flip
flop that genreates a one clock long reset pulse?

Lots of logic? three gates and a FF or two?

The 'Auto-Lock' suggestion is a good one. We will keep that in mind.

Austin

 

[Peter Alfke]

I am embarrassed. I fell into the "fix metastability trap".
To quote a German proverb:
"Alter schuetzt vor Torheit nicht" (Age is no protection against stupidity).

So, before anybody starts experimenting:
Three or more flip-flops with majority voting are no cure for
metastability, they just protract the agony. And so do all sorts of
other schemes. All of them!
But, as Hal wrote, just waiting helps. And you do not have to wait very
long. Clocking the synchronizer result at 300 MHz into a second
flip-flop gives you the "wrong" result once in a billion years. ( and we
can debate what is actually right or wrong ).
The uncertainty of 0 or 1 is never the issue in metastability ( either
answer is as good as the other), it is the unpredictable timing that is
the bummer. Since that range of unpredictability (is that a word?) is
statistically less than 2 ns for any reasonable probability, we can
ignore metastability in all but the very fastest applications.

But we cannot fix it, not with voting, nor with hysteresis, nor with any
other contraptions.

My thanks to Bob Perlman for kicking me in the shins. It's good to have
friends.
Peter Alfke

 

[Austin Lesea]

What is it for?

Helps to know why you want/need a free sample.

Austin

NOSPAM@NOSPAM.invalid.com wrote:

Hello,
Please, does anybody know if there's any FPGA manufacturer
that will give a sample FPGA for free?

Thank You!

 

[Peter Alfke]

High-volume manufacturers of any kind are not equipped to efficiently
handle low-quantity sales or give-aways. Thats what distributors do for
a living. They might even give you a sample. It all depends on their
expectations (and their mood).
FPGA manufacturers usually have friendly and generous relationships with
many universities. I know Xilinx does..
Peter Alfke



NOSPAM@NOSPAM.invalid.com wrote:

Hello,
Please, does anybody know if there's any FPGA manufacturer
that will give a sample FPGA for free?

Thank You!

 

[Pablo Bleyer Kocik]

"Jim Kearney" <replace.this.with.my.forename@jkearney.com> wrote in message news:<d2x2b.260397$uu5.60519@sccrnsc04>...

"Pablo Bleyer Kocik" <pablobleyer@hotmail.com> wrote in message
Exactly, this is what I was referring to. Sorry if it was not clear.
I want to share the same CCLK line for another purpose after the FPGA
has been configured. This will be a toggling 5V signal. Will the
(sleeping) CCLK will have any concerns with that?

Here is some official documentation - look at Answer # 10046 in Xilinx's
Answer Database. If this applies to Virtex, I believe it should to the
Spartan II as well, since it is a derivative device.

Jim, thank you very much. I had missed that answer (only looked up
for Spartan). I think that will do.

Regards!

 

[Nicholas C. Weaver]

In article <wAL2b.266624$lK4.8275187@twister1.libero.it>,
<NOSPAM@NOSPAM.invalid.com> wrote:

Hello,
Please, does anybody know if there's any FPGA manufacturer
that will give a sample FPGA for free?

Well, for small parts, Digikey isn't free, but is cheap, as you can
get single unit parts for <$20.

--
Nicholas C. Weaver nweaver@cs.berkeley.edu

 

[Andrew Paule]

When we used to context switch, it was a call gate/semiphore arrangment
(software guys have a better concept of this most of the time - I did
the hardware, the software guys yelled at me, so I leaned to build
shadow registers like the long lost 960's - 1 clock context switch
processors). A context switch is moving from one task to another, and
saving what you need to get back to working on the present task -
interrupt service is a great example. In an ASIC or FPGA, if you want
to context switch, you just need to shift register outs unless you are
building a processor in the thing. If that's the case, it can be as
little as 1 clock - if you are building something to do it. How fast a
context switch is a meaningless thing in this sense, it depends on how
the architecture in the chip is defined.

Andrew

Kuan Zhou wrote:

Hi,
I am wondering how fast can the Virtex does the context switch.
I heard it's slow because the CMOS response very slowly. Is it true?

Thank you very much!


sincerely
-------------
Kuan Zhou
ECSE department

 

[Andrew Paule]

guy's in italy -should just call the local disti's and reps.

Peter Alfke wrote:

High-volume manufacturers of any kind are not equipped to efficiently
handle low-quantity sales or give-aways. Thats what distributors do for
a living. They might even give you a sample. It all depends on their
expectations (and their mood).
FPGA manufacturers usually have friendly and generous relationships with
many universities. I know Xilinx does..
Peter Alfke



NOSPAM@NOSPAM.invalid.com wrote:


Hello,
Please, does anybody know if there's any FPGA manufacturer
that will give a sample FPGA for free?

Thank You!

 

[Greg Steinke]

Hello,
When using passive parallel asynchronous (PPA) mode, the APEX device
has a built-in oscillator that controls its response to the nWS and
other signals. There is some variation of this oscillator's speed
depending on temperature, voltage, and process.

When you drive nWS low then high, the device captures the byte of data
on the DATA[7..0] bus and then starts to process it, clocked by the
internal oscillator. During this time it will drive the RDYnBSY line
low. When it drives the RDYnBSY line high, it has completed.

When you drive in the final byte of data, the device will drive
RDYnBSY low then high. CONF_DONE will not be released until after it
has driven RDYnBSY high again. On an APEX 20KE device, tBUSY (the time
during which RDYnBSY is low) ranges from 0.4 to 1.6 microseconds.

Note that the configuration files that Quartus II software generates
include some number of 1s at the end of the file. The reason for doing
so is that with other configuration modes (such as passive serial),
the system must clock the device after CONF_DONE goes high to get it
into user mode. Quartus II adds the extra bits so that a user can just
drive in the whole file and by doing so clock the device enough times
to initialize it - the user does not have to drive in the data and
then separately clock it. A small thing but it makes it easier to use.
When using PPA, this means that CONF_DONE will go high before you have
sent in the entire file. If you have chosen the internal oscillator as
the clock source for initializing the device, the device may even
enter user mode before you have sent in the entire file. (This choice
is one of the device options, chosen when you select the configuration
mode).

Finally, note that depending on your use of the dual-purpose pins,
there may be no harm in sending in the entire configuration file, and
doing so can make the system design a little easier. For example, the
data bus pins DATA[7..1] are used for configuration in PPA mode, but
may take on a different functionality in user mode. If those pins are
programmed to be inputs in user mode, then continuing to drive in the
extra 1s at the end of the configuration file will be ok. But if they
are programmed to be outputs, then you could have contention.

So the short answer to your question is that CONF_DONE will go high
after RDYnBSY goes low then high again. The long answer is that
depending on the overall setup, sending the extra bytes may not
matter.

Sincerely,
Greg Steinke
gregs@altera.com
Altera Corporation





anfm@ele.pku.edu.cn (pkuanfm) wrote in message news:<15ecef93.0308242303.7fb269e9@posting.google.com>...

hello,everyone,i am trying to configure apex20k200e-1x using ppa
scheme.i have read the altera databook an116.in figure 24 of page 42,i
learned that after sending the last byte ,the signal "conf_done" go
high. i want to know how much time after the nws go high,conf_done can
go high. it will result in some extra bytes being sent to apex20k if
the delay time is too long, because i check the signal conf_done to
judge whether the confige is complete.

 

[Peter Alfke]

Some years ago, papers were given about an FPGA with multiple stored
configurations, where the FPGA could switch "everything" in a few
nanoseconds. It created some interest, but never saw the light-of-day.
It takes more than a clever idea to create a viable product, sigh, sigh...

Peter Alfke
=====================

 

[Greg Steinke]

Michele,
While the Cyclone device is not directly compliant to 5V interfaces,
there are some possible techniques for solving this problem. I don't
know the exact requirements for a 5V parallel interface, but the
following applies to 5V interfaces in general. Let's consider the
input and the output sides:

Input (driving to the Cyclone device):
The key here is that the Vin must never exceed 4.1 V (the maximum
Cyclone device recommended operating conditions show in the
datasheet). With a 5V driver this can be a problem. However, you can
use a simple external circuit to ensure that Vin is below 4.1V. The
basic idea is that you use a series resistor and a diode connected to
the 3.3V supply. The diode limits the maximum excursion of the Vin,
and the resistor limits the current from the 5V driver through the
diode to the 3.3V supply. We have published a design based on this
technique for APEX 20KE devices, shown here:
http://www.altera.com/literature/wp/wp5Vapex1.02.pdf
We have not worked out the details for Cyclone devices, but the same
basic idea holds.

Another option is to use a QuickSwitch device from IDT, as shown in
this document:
http://www.idt.com/docs/AN_11.pdf

Output (driving from Cyclone):
This may be much simpler. 3.3V LVTTL and 5.0V TTL share the same VOH
and VOL specs. Cyclone devices can drive 3.3V LVTTL. So if the
parallel port uses 5V TTL specs then there's no problem. However, if
it uses 5V CMOS, then there is an issue since the VIH for 5V CMOS is
higher than the VOH for 3.3V LVTTL. You can't simply use a pullup
resistor to 5V since you then are pulling the Cyclone pin too high as
well. So if the interface is 5V CMOS then you would probably need an
external buffer.

You also may want to consider using an ACEX 1K or FLEX 10KE device.
The advantage here is that it is natively 5V-tolerant, so there's
nothing special to do. The output is still LVTTL, so driving 5V TTL is
no problem but driving 5V CMOS would require a buffer. The driving
factor behind this choice would be performance, density, perhaps
price. The biggest Cyclone device is bigger than the biggest ACEX 1K
or FLEX 10KE device, which may be relevant to your design.

One of the options discussed here ought to implement what you need.
Have fun!

Sincerely,
Greg Steinke
gregs@altera.com
Altera Corporation



"michele bergo" <michelebergo@libero.it> wrote in message news:<j2k2b.263317$Ny5.8106349@twister2.libero.it>...

I want to interface altera cyclone(3.3V) to the pc parallel port(5V). Is it
possible without using further external devices?

Thanks

 

[Greg Steinke]

Matt,
Generally speaking, this kind of problem indicates that the device did
not correctly receive the preamble to the configuration bitstream, and
therefore did not start to process the data. This explains why nSTATUS
doesn't go low; the device has not yet started to look at the CRC for
each frame of data.

The #1 reason for configuration issues is signal integrity issues on
the DCLK signal. Even though it is running pretty slow, it's still a
clock and therefore sensitive to ringing. The ringing causes
double-clocking on the FPGA, so it sees a given bit twice. To diagnose
this, probe at the DCLK on the Cyclone device as close as you can and
observe the signal. If probing it makes it work, then it's signal
integrity as the capacitance of the probe is damping the ringing. Or
maybe you'll see ringing. Putting in a series termination at the
microprocessor, or a parallel termination at the Cyclone, will
generally solve this problem.

Other things to check:
- signal integrity on the DATA signal. Usually not a problem, but
possible.
- When you send the data to the Cyclone, make sure you send each byte
LSB first.

One of these is most likely the problem.

Sincerely,
Greg Steinke
gregs@altera.com
Altera Corporation


matt@ettus.com (Matt Ettus) wrote in message news:<e8fd79ea.0308241714.6bc21e24@posting.google.com>...

I am trying to configure a Cyclone EP1C12 using a microprocessor.
Basically, I pull nConfig high, and wait for nStatus to go high. Once
it does, I start loading data. When it is done, I never get CONF_DONE
going to high indicate success. Also, I never get nStatus going low
again to indicate failure either.

I've tried clocking in millions of zeros after my bitstream, but that
doesn't change anything.

Any ideas?

Thanks
Matt

 

[nospam]

Peter Alfke <peter@xilinx.com> wrote:

I am embarrassed. I fell into the "fix metastability trap".
To quote a German proverb:
"Alter schuetzt vor Torheit nicht" (Age is no protection against stupidity).

So, before anybody starts experimenting:
Three or more flip-flops with majority voting are no cure for
metastability, they just protract the agony. And so do all sorts of
other schemes. All of them!

I proposed some time ago that injecting a high frequency signal into the FF
feedback path would limit metastabilty maximum duration.

You drop a pin onto a table now and then it will land perfectly balanced on
its point, how long it stays upright depends on how well it was balanced.

Vibrate the table and it will stay upright for less time.

 

[Hal Murray]

I proposed some time ago that injecting a high frequency signal into the FF
feedback path would limit metastabilty maximum duration.

You drop a pin onto a table now and then it will land perfectly balanced on
its point, how long it stays upright depends on how well it was balanced.

Vibrate the table and it will stay upright for less time.

I don't think so.

This is another example of a "fix". They don't work. The only question
is can you see why they don't work?

In this case, the vibrations will kick some pins that have started to
fall back to the ballancing point.

--
The suespammers.org mail server is located in California. So are all my
other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited
commercial e-mail to my suespammers.org address or any of my other addresses.
These are my opinions, not necessarily my employer's. I hate spam.

 

[Sasa Bremec]

Ray thanks for the answer! Searching this forum I also found your past

answers to this question.

You are missing some key pieces of information: the available clock

frequency

(this is different than the sample rate), and the target FPGA family.

The device is Virtex2 Pro. Its system clock is 108MHz or 125 MHz not decided

yet. And the filter coefficients are constant (not reconfigurable).



I have some additional question about FIR filter and its decimation

capability.



In my DDC after a CIC filter I would like to place this FIR filter, the

question is:



Is better to use FIR with decimation capability, or to use higher decimation

rate in CIC filter and use the FIR only as low pass filter?



CIC decimation is 32



FIR decimation is 4



The second way will allow me to do a time multiplex of this FIR because I

will have instead of 1/32 Fs the 1/128 Fs and also the number of taps will

be reduced, is this correct. Also this Fs is low enough to use MAC FIR.



Best regards, Sasa

 

[rickman]

Jon Elson wrote:

Well, just because the manufacturer isn't putting the info in the data
sheets, and don't
test for it, I suspect that you could get a rough description that could
be quite helpful.
Knowing, for instance, that the strobes will always follow a CPU clock
by at least
1 ns, and never change than 5 nS after the clock, would make designing a
synchronous
memory/peripheral controller running from the same clock a lot simpler.

Except that you don't know that this won't change if they tweek the chip
design. It could very easily be 1 to 5 ns delay now and then change to
5 to 10 ns when they switch to a new process for cost savings. The 5 to
10 ns delay will put it right at the falling edge where I would likely
be clocking it in with the old numbers.

If you can just get the roughest of descriptions of the clock vs.
strobes circuitry, you
can improve the system performance greatly, because you don't have to
have ranked
FFs on every strobe.

Now, on the high speed stuff, with clock multipliers, etc. it can get
quite complex, and
a CPU swap to the next higher speed can throw everything off due to a
change in clock
multiplier. But, I gathered from the initial post that this wasn't a
clock multiplied CPU.

Actually, yes the MCU runs at 8x or 4x the input clock. But the output
is at the MCU rate and I will be clocking the FPGA with the 8x MCU
output clock.

--

Rick "rickman" Collins

rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design URL http://www.arius.com
4 King Ave 301-682-7772 Voice
Frederick, MD 21701-3110 301-682-7666 FAX

 

[Peter Alfke]

Well, the "pin is falling over" in 2 ns anyhow, so how fast can you
"shake the table"?
We are not worried about microseconds of metastability anymore...
Peter Alfke

nospam wrote:

Peter Alfke <peter@xilinx.com> wrote:

I am embarrassed. I fell into the "fix metastability trap".
To quote a German proverb:
"Alter schuetzt vor Torheit nicht" (Age is no protection against stupidity).

So, before anybody starts experimenting:
Three or more flip-flops with majority voting are no cure for
metastability, they just protract the agony. And so do all sorts of
other schemes. All of them!

I proposed some time ago that injecting a high frequency signal into the FF
feedback path would limit metastabilty maximum duration.

You drop a pin onto a table now and then it will land perfectly balanced on
its point, how long it stays upright depends on how well it was balanced.

Vibrate the table and it will stay upright for less time.