S
Steve Casselman
Guest
If you see it in the simulation then there is a good chance that it is going
to happen in the hardware. If you see it in hardware you may be able to
reproduce it in the simulator.
That is life.
Steve
to happen in the hardware. If you see it in hardware you may be able to
reproduce it in the simulator.
That is life.
Steve
A
Avrum
Guest
You haven't really given us enough information - you should post a little
more about the problem; are you getting an error or warning from the
simulation, and if so, what exactly is happening around the time of the
error. Also we need to know a little more about your application.
Are you using the same clock for both ports of the ram (i.e. are CLKA and
CLKB driven from the same BUFG). If so, there is one condition where reading
and writing to the same address is legal - if the port doing the write is
set to "READ_FIRST" (an attribute set on the RAM), then the data returned
from the read port is the previous contents of the RAM. You also don't
specify if the two ports of the RAM are the same widths.
That being said, you say that you have "logic to avoid hits over the same
address", meaning you are (trying to) guarantee that you never attempt a
simultaneous read and write to the same address. In the past, we have had
some problems with the simulation models of the CoreGen RAMs; we definately
had situations where the model would erroneously declare a read/write
conflict (i.e. there have been bugs in the simulation models in the past).
So, the question is, are you sure there is no conflict. It should be easy to
verify by looking at the waveforms (capuring all the inputs and outputs of
the Dual Port RAM in question). If you are getting an error, look at the
waveforms around this error to determine if you are indeed writing and
reading to the same address (or similar addresses) at the same time.
Remember, if the port wirths of the two ports are not the same, then the
"same address" from the point of view of the RAM is not simply ADDRA ==
ADDRB; if portA is 16 bits wide and portB is 4 bits wide then a contention
exists when ADDRB/4==ADDRA
Avrum
"Nap" <nap@4plus.com> wrote in message
news:4ca417fe.0307040701.52e71a46@posting.google.com...
more about the problem; are you getting an error or warning from the
simulation, and if so, what exactly is happening around the time of the
error. Also we need to know a little more about your application.
Are you using the same clock for both ports of the ram (i.e. are CLKA and
CLKB driven from the same BUFG). If so, there is one condition where reading
and writing to the same address is legal - if the port doing the write is
set to "READ_FIRST" (an attribute set on the RAM), then the data returned
from the read port is the previous contents of the RAM. You also don't
specify if the two ports of the RAM are the same widths.
That being said, you say that you have "logic to avoid hits over the same
address", meaning you are (trying to) guarantee that you never attempt a
simultaneous read and write to the same address. In the past, we have had
some problems with the simulation models of the CoreGen RAMs; we definately
had situations where the model would erroneously declare a read/write
conflict (i.e. there have been bugs in the simulation models in the past).
So, the question is, are you sure there is no conflict. It should be easy to
verify by looking at the waveforms (capuring all the inputs and outputs of
the Dual Port RAM in question). If you are getting an error, look at the
waveforms around this error to determine if you are indeed writing and
reading to the same address (or similar addresses) at the same time.
Remember, if the port wirths of the two ports are not the same, then the
"same address" from the point of view of the RAM is not simply ADDRA ==
ADDRB; if portA is 16 bits wide and portB is 4 bits wide then a contention
exists when ADDRB/4==ADDRA
Avrum
"Nap" <nap@4plus.com> wrote in message
news:4ca417fe.0307040701.52e71a46@posting.google.com...
P
Peter Ryser
Guest
Hi Lan,
you should not need to do any of this. After opening a V2PDK shell (Windows) or sourcing
v2pro_setup (Solaris) change into your project directory. After editing flow.cfg (if necessary)
type "make synth". Synplify will open (if you didn't chose to add -batch in flow.cfg) and you can
synthesize the design. After leaving synplify type "make fpga" to start the implementation
followed by "make bit" to generate the bitstream.
- Peter
Lan Nguyen wrote:
you should not need to do any of this. After opening a V2PDK shell (Windows) or sourcing
v2pro_setup (Solaris) change into your project directory. After editing flow.cfg (if necessary)
type "make synth". Synplify will open (if you didn't chose to add -batch in flow.cfg) and you can
synthesize the design. After leaving synplify type "make fpga" to start the implementation
followed by "make bit" to generate the bitstream.
- Peter
Lan Nguyen wrote:
L
Lan Nguyen
Guest
thanks Peter,
it's working
Peter Ryser <ryserp@xilinx.com> wrote in message news:<3F2FE7B1.3C47DABD@xilinx.com>...
it's working
Peter Ryser <ryserp@xilinx.com> wrote in message news:<3F2FE7B1.3C47DABD@xilinx.com>...
V
Vaughn Betz
Guest
kjaram_junk@cox.net (Ken Jaramillo) wrote in message news:<75cebfa6.0308071755.37541a3@posting.google.com>...
The Optimize Hold Time algorithm in Quartus 3.0 is smart enough to
know where to add delay to fix Th without violating Tsu, if possible.
So the behaviour you're seeing where fixing the hold violations causes
setup violations is not generally expected.
That said, there are cases where we cannot fix Th without causing
problems on Tsu.
1. Your circuit is such that the connections to which we have to add
delay to fix a Th violation are also on another, Tsu-critical
connection. If we add delay to resolve Th, we will violate Tsu. The
only solution here is to re-work your circuit.
2. A sub-case of #1 above: the only part of a timing path to which
we could add delay to meet a Th constraint at a register, without
violating some Tsu constraint, is on the last LUT->reg connection on
the Th path. If Quartus register packs this LUT and register together
into one logic cell, a dedicated routing connection is used to make
the connection from the LUT to the register, so we can't slow it down
by adding more routing. The workaround to this is to set a constraint
to force the LUT & register to be kept in separate logic cells. In
our in-house PCI core, we have to turn off register packing on two
banks of registers to allow the router the flexibility to fix the hold
time problem. The constraint we set (in the <project.esf> file) is:
AUTO_PACKED_REGISTERS_STRATIX = OFF on low_ad_or_fb[] and
high_ad_or_fb[]
If your PCI core uses similar names / has a similar structure this may
give you an idea of what to register unpack. Looking at whether or
not the registers at which you're having Tsu / Th problems were packed
with LUTs in the Quartus floorplan editor will also let you see what's
going on.
3. The same as #2, but the register and LUT were packed together by
your synthesis tool. Depending on your synthesis tool, you may be
able to tell it not to do this (but it'll be tool specific).
4. I've never tested the optimize hold time algorithm in cases where
someone has inserted logic cells to slow down the clock (this isn't a
common technique). It is possible Quartus is mis-estimating the delay
at the point where the algorithm kicks in, and hence Quartus thinks
it's OK on Tsu and Th, but is not. If you send me your circuit, I can
see if this is the case, and if necessary upgrade Quartus to model
this better.
5. You can buy Altera's PCI core. It works with Cyclone, and there
are 32-bit and 64-bit versions. You can try it out (instantiate,
simulate, place and route, timing analyze -- basically see that it
works) for free, but have to buy it to generate programming files.
See the Interfaces & Peripherals category on
http://www.altera.com/products/ip/ipm-index.html
The best way for me to give you more guidance on what went wrong and
how you can fix it is for you to send a Quartus archive of your design
to me. All such designs are treated as confidential -- we will use it
in house only as a test case to improve our software.
Regards,
Vaughn
Altera
Hi Ken,
The Optimize Hold Time algorithm in Quartus 3.0 is smart enough to
know where to add delay to fix Th without violating Tsu, if possible.
So the behaviour you're seeing where fixing the hold violations causes
setup violations is not generally expected.
That said, there are cases where we cannot fix Th without causing
problems on Tsu.
1. Your circuit is such that the connections to which we have to add
delay to fix a Th violation are also on another, Tsu-critical
connection. If we add delay to resolve Th, we will violate Tsu. The
only solution here is to re-work your circuit.
2. A sub-case of #1 above: the only part of a timing path to which
we could add delay to meet a Th constraint at a register, without
violating some Tsu constraint, is on the last LUT->reg connection on
the Th path. If Quartus register packs this LUT and register together
into one logic cell, a dedicated routing connection is used to make
the connection from the LUT to the register, so we can't slow it down
by adding more routing. The workaround to this is to set a constraint
to force the LUT & register to be kept in separate logic cells. In
our in-house PCI core, we have to turn off register packing on two
banks of registers to allow the router the flexibility to fix the hold
time problem. The constraint we set (in the <project.esf> file) is:
AUTO_PACKED_REGISTERS_STRATIX = OFF on low_ad_or_fb[] and
high_ad_or_fb[]
If your PCI core uses similar names / has a similar structure this may
give you an idea of what to register unpack. Looking at whether or
not the registers at which you're having Tsu / Th problems were packed
with LUTs in the Quartus floorplan editor will also let you see what's
going on.
3. The same as #2, but the register and LUT were packed together by
your synthesis tool. Depending on your synthesis tool, you may be
able to tell it not to do this (but it'll be tool specific).
4. I've never tested the optimize hold time algorithm in cases where
someone has inserted logic cells to slow down the clock (this isn't a
common technique). It is possible Quartus is mis-estimating the delay
at the point where the algorithm kicks in, and hence Quartus thinks
it's OK on Tsu and Th, but is not. If you send me your circuit, I can
see if this is the case, and if necessary upgrade Quartus to model
this better.
5. You can buy Altera's PCI core. It works with Cyclone, and there
are 32-bit and 64-bit versions. You can try it out (instantiate,
simulate, place and route, timing analyze -- basically see that it
works) for free, but have to buy it to generate programming files.
See the Interfaces & Peripherals category on
http://www.altera.com/products/ip/ipm-index.html
The best way for me to give you more guidance on what went wrong and
how you can fix it is for you to send a Quartus archive of your design
to me. All such designs are treated as confidential -- we will use it
in house only as a test case to improve our software.
Regards,
Vaughn
Altera
A
Anil Khanna
Guest
As far as cost goes, it again comes down to what you are trying to achieve.
Many times, the cost of the tools could be justified easily by showing the
savings - for example, saving a speedgrade (use a slower speedgrade part) by
the use of physical synthesis has a great impact on the total cost of your
board.
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.
As FPGAs are getting bigger and can accomodate complex designs, there are
newer physical synthesis tools in the market that have different approaches
to solving the timing closure issue. It is definitely worthwhile to check
them out.
"Christian Schneider" <cgs-news@cgschneider.com> wrote in message
news:bidt5i$83ehs$1@ID-68826.news.uni-berlin.de...
Many times, the cost of the tools could be justified easily by showing the
savings - for example, saving a speedgrade (use a slower speedgrade part) by
the use of physical synthesis has a great impact on the total cost of your
board.
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.
As FPGAs are getting bigger and can accomodate complex designs, there are
newer physical synthesis tools in the market that have different approaches
to solving the timing closure issue. It is definitely worthwhile to check
them out.
"Christian Schneider" <cgs-news@cgschneider.com> wrote in message
news:bidt5i$83ehs$1@ID-68826.news.uni-berlin.de...
A
Andrew Paule
Guest
Hi Bob:
guess I'm flattered that Hal is getting to defend some of the aspects
here - what I am pointing out is that in a standard flop design, there
are two balanced P/N nodes (assuming you're building a MOS flop - very
few done otherwise anymore) that are used to jam another pair that sets
the output. The balancing that takes place will only force the output
if there is thermal noise - this is how Fiarchild, Intel, and most
others build the things. Take a poke around the net for articles by
Dike and Burton - they have done more work on metastability that almost
anyone else out there, and IEEE uses their work as a standard for this
stuff. I'm not the author, just parroting what others have done.
The amount of noise is not a factor (this is thermal noise, and all
gates exhibit about 9nV per root kT) - thanks boltzman - but the effects
of Miller coupling is as of yet not well understood, at least by me.
Andrew
Bob Perlman wrote:
guess I'm flattered that Hal is getting to defend some of the aspects
here - what I am pointing out is that in a standard flop design, there
are two balanced P/N nodes (assuming you're building a MOS flop - very
few done otherwise anymore) that are used to jam another pair that sets
the output. The balancing that takes place will only force the output
if there is thermal noise - this is how Fiarchild, Intel, and most
others build the things. Take a poke around the net for articles by
Dike and Burton - they have done more work on metastability that almost
anyone else out there, and IEEE uses their work as a standard for this
stuff. I'm not the author, just parroting what others have done.
The amount of noise is not a factor (this is thermal noise, and all
gates exhibit about 9nV per root kT) - thanks boltzman - but the effects
of Miller coupling is as of yet not well understood, at least by me.
Andrew
Bob Perlman wrote:
B
Bob Perlman
Guest
Andrew -
Thanks for the reply. The Burton/Dike 1999 paper on Miller Effect
sounds interesting; I'll try to get a copy.
Bob Perlman
On Sun, 31 Aug 2003 22:31:39 -0500, Andrew Paule <lsboogy@qwest.net>
wrote:
Thanks for the reply. The Burton/Dike 1999 paper on Miller Effect
sounds interesting; I'll try to get a copy.
Bob Perlman
On Sun, 31 Aug 2003 22:31:39 -0500, Andrew Paule <lsboogy@qwest.net>
wrote:
L
Luiz Carlos
Guest
Rick, the electron spin is +1/2 or -1/2, there is no in between state,
it changes instantaneously (in one fundamental clock tick, ~10^-43
seconds).
Luiz Carlos
L
Luiz Carlos
Guest
Hi Austin.
First, as Andrey pointed out, I took the wrong table.
The best values are for GTL:
Vout = low, if Vin <= Vref - 0.05
Vout = high, if Vin >= Vref + 0.05
versus offset formula.
But, let's suppose we didn't reach the offset value. If we range Vin
from Vref-Voffset to Vref+Voffset, I think Vout will range from Vlow
to Vhigh monotonically, maybe almost linearly. Am I right?
Now, if we sample Vout with the input data flip-flop, FF DOUT will be
0 or 1 (forget about metastability for now). Can I say there is Vthr
where: if Vout>Vthr then DOUT=1 and if Vout<Vthr then DOUT=0? What
does happen when we feed a data flip-flop with an analog signal?
I also would like to know if when we define an input as LVTTL (for
example), the same input comparator is used (Vref connected to an
internal reference), or if it is bypassed.
Luiz Carlos
First, as Andrey pointed out, I took the wrong table.
The best values are for GTL:
Vout = low, if Vin <= Vref - 0.05
Vout = high, if Vin >= Vref + 0.05
I really would like to know what this offset is and to have a speed
versus offset formula.
But, let's suppose we didn't reach the offset value. If we range Vin
from Vref-Voffset to Vref+Voffset, I think Vout will range from Vlow
to Vhigh monotonically, maybe almost linearly. Am I right?
Now, if we sample Vout with the input data flip-flop, FF DOUT will be
0 or 1 (forget about metastability for now). Can I say there is Vthr
where: if Vout>Vthr then DOUT=1 and if Vout<Vthr then DOUT=0? What
does happen when we feed a data flip-flop with an analog signal?
I also would like to know if when we define an input as LVTTL (for
example), the same input comparator is used (Vref connected to an
internal reference), or if it is bypassed.
Luiz Carlos
L
Luiz Carlos
Guest
Yes John.
But, if I can have one for free, why not use it?
Even if it doesn't fit my needs, the knowledge remains.
Luiz Carlos
A
Austin Lesea
Guest
Luiz,
Last things first, the LVTTL input does not use the comparator(s) (there are
three different comparators, as well as other ciruits for the various input
standards).
The comparator is designed to have a relatively high gain, so that it
switches quickly.
As I said, the offset voltage is due to the Vt mismatch on the pmos and nmos
diff pairs, and since these are built with .35u (VII) or .25u (VII Pro)
transistors, they are pretty darn fast diff-amps. There is a classic gain
stage after the cmos diff-amp (similar to the ones in "CMOS Circuit Design,
Layout & Simulation" by Baker, Li, and Boyce). The offset voltage is
typically less than a few 10's of mV (say 10 to 20 mV worst case). I am sure
that if you vary the voltage difference slowly enough, you could measure the
gain of the diff-amp. It was designed for HSTL and SSTL IO standards, which
as someone already pointed out, are pretty sloppy. What I will point out
here, is that I am not aware of any monolithic separate comparator that is as
fast as the one that is in the input circuit. This comparator is good for
400 Mbs+ speeds, which is a lot faster than most separate IC comparators....
Austin
Luiz Carlos wrote:
Last things first, the LVTTL input does not use the comparator(s) (there are
three different comparators, as well as other ciruits for the various input
standards).
The comparator is designed to have a relatively high gain, so that it
switches quickly.
As I said, the offset voltage is due to the Vt mismatch on the pmos and nmos
diff pairs, and since these are built with .35u (VII) or .25u (VII Pro)
transistors, they are pretty darn fast diff-amps. There is a classic gain
stage after the cmos diff-amp (similar to the ones in "CMOS Circuit Design,
Layout & Simulation" by Baker, Li, and Boyce). The offset voltage is
typically less than a few 10's of mV (say 10 to 20 mV worst case). I am sure
that if you vary the voltage difference slowly enough, you could measure the
gain of the diff-amp. It was designed for HSTL and SSTL IO standards, which
as someone already pointed out, are pretty sloppy. What I will point out
here, is that I am not aware of any monolithic separate comparator that is as
fast as the one that is in the input circuit. This comparator is good for
400 Mbs+ speeds, which is a lot faster than most separate IC comparators....
Austin
Luiz Carlos wrote:
A
Austin Lesea
Guest
John,
Uh, it is an anolog comparator....just one optimized for HSTL and SSTL inputs.
Comments about noise are well put, and need to be considered if the comparator
is on the same chip, on the same board.
But to imply that we could somehow be sloppy, and design a crummy comparator is
a bit unfair, the comparator is probably much better than any single device you
could name, it is just that we did not characterize any more than we had to.
Austin
John_H wrote:
Uh, it is an anolog comparator....just one optimized for HSTL and SSTL inputs.
Comments about noise are well put, and need to be considered if the comparator
is on the same chip, on the same board.
But to imply that we could somehow be sloppy, and design a crummy comparator is
a bit unfair, the comparator is probably much better than any single device you
could name, it is just that we did not characterize any more than we had to.
Austin
John_H wrote:
H
Hal Murray
Guest
DING DING DING
Nobody has been able to fix metastability yet. If you really have
a fix, it's worth a Nobel Prize.
The usual problem with that sort of approach is that you get
a runt pulse on the fix-it signal in cases that would have worked
correctly without it.
--
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.
N
Nicholas C. Weaver
Guest
In article <3F559A3F.91184B1A@yahoo.com>,
rickman <spamgoeshere4@yahoo.com> wrote:
that it is in the intermediate state at some fixed interval after the
clock, and then force the flop one way or another. Of course, it
might double-glitch in the meantime (flop goes up before logic forces
it down), but it would make a flop with a fixed-maximum metastabel
interval.
Of course, it seems like such a massive headache to do.
IN THE COMPUTATION is the critical path. EG, if 9 of the stages take
1 ns, and the last takes 2ns, but the last only affects 1/2 the data,
with the asynchronous circuitry doing the shortcutting, it will be
considerably faster than the synchronous one.
The problem is: You can automatically balance the pipelining
(retiming) for a synchronous circuit, while asynchronous really playes
havoc with the CAD flow and testing.
--
Nicholas C. Weaver nweaver@cs.berkeley.edu
rickman <spamgoeshere4@yahoo.com> wrote:
Silly question: I don't see why an ANALOG flip-flop couldn't determine
that it is in the intermediate state at some fixed interval after the
clock, and then force the flop one way or another. Of course, it
might double-glitch in the meantime (flop goes up before logic forces
it down), but it would make a flop with a fixed-maximum metastabel
interval.
Of course, it seems like such a massive headache to do.
The trick with asynchronous logic is that the longest stage WHICH IS
IN THE COMPUTATION is the critical path. EG, if 9 of the stages take
1 ns, and the last takes 2ns, but the last only affects 1/2 the data,
with the asynchronous circuitry doing the shortcutting, it will be
considerably faster than the synchronous one.
The problem is: You can automatically balance the pipelining
(retiming) for a synchronous circuit, while asynchronous really playes
havoc with the CAD flow and testing.
--
Nicholas C. Weaver nweaver@cs.berkeley.edu
N
Nicholas C. Weaver
Guest
In article <vlc0kv1m4flm5f@corp.supernews.com>,
Hal Murray <hmurray@suespammers.org> wrote:
which is the key requirement, as "did the data come before or after
the clock edge" is really an irrelevant question at the metastable
capture point, you jsut want it to go to ONE or the other (not stick
around and make up its mind a half clock cycle later), and possibly to
tell you.
This isn't FIXING metastability, this is detecting and responding to
it, changing an exponentially decaying bounds into a fixed bounds.
Of course, it seems like way too big a headache to bother with.
--
Nicholas C. Weaver nweaver@cs.berkeley.edu
Hal Murray <hmurray@suespammers.org> wrote:
Yes, but the point is it would fix the maximum metastability window,
which is the key requirement, as "did the data come before or after
the clock edge" is really an irrelevant question at the metastable
capture point, you jsut want it to go to ONE or the other (not stick
around and make up its mind a half clock cycle later), and possibly to
tell you.
This isn't FIXING metastability, this is detecting and responding to
it, changing an exponentially decaying bounds into a fixed bounds.
Of course, it seems like way too big a headache to bother with.
--
Nicholas C. Weaver nweaver@cs.berkeley.edu
R
Ray Andraka
Guest
The problem is with your three level "analog ff", instead of one metastable
region, you now have two, one at each side of your middle state. All it
accomplishes is a redistribution of the metastable state at a cost of
considerably more complexity. It doesn't fix anything at all. As rickman and
others have stated, it comes down to a fundamental limitation in measuring a
quantity. Measurement takes a finite amount of time to do. If the transition
happens within that measurement window, you have a metastable event, which is
to say the measurement was indeterminate. Works for digital logic, works for
electron spins and so on. If you really believe you have a work-around, then
you should publish it. Be prepared to nurture your wounds though. The paths
to the holy metastability grail is littered with bloodied bodies, many of whom
have followed the same trail you are considering.
"Nicholas C. Weaver" wrote:
--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
region, you now have two, one at each side of your middle state. All it
accomplishes is a redistribution of the metastable state at a cost of
considerably more complexity. It doesn't fix anything at all. As rickman and
others have stated, it comes down to a fundamental limitation in measuring a
quantity. Measurement takes a finite amount of time to do. If the transition
happens within that measurement window, you have a metastable event, which is
to say the measurement was indeterminate. Works for digital logic, works for
electron spins and so on. If you really believe you have a work-around, then
you should publish it. Be prepared to nurture your wounds though. The paths
to the holy metastability grail is littered with bloodied bodies, many of whom
have followed the same trail you are considering.
"Nicholas C. Weaver" wrote:
--
--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
C
Chen Wei Tseng
Guest
Rider,
When configuring the FPGA via JTAG, iMPACT will provide TCK. When
configuring the FPGA via PROM with Master Serial Setup, CCLK is provided
by the FPGA.
At the end of configuration, the FPGA will enter the startup sequence.
Treat this sequence as a state machine that the FPGA needs to go through
before "waking up". This sequence is where you can set the options of
when you want the DONE pin to go high, the IO tri-state to be released,
etc.
To get through this startup sequence, you'll need to provide clocks.
Generally, when configuring via JTAG, you would select startup clock to
be JTAGCLK since you're already providing TCK. So when configuring with
PROM, you would want to set startup clock to CCLK unless you'll be
seperating providing TCK (JTAGCLK) or even userclock to clock through
the startup sequence.
And as for PROM file generation or ACE file generation, the iMPACT help
topic has been vastly improved in 6.1i. If anything isn't clear, please
do contact the Xilinx Hotline Support.
As far as support for patform flash proms, please make sure you use 5.2i
service pack 3 for file generation.
Regards, Wei
Xilinx Applications
rider wrote:
When configuring the FPGA via JTAG, iMPACT will provide TCK. When
configuring the FPGA via PROM with Master Serial Setup, CCLK is provided
by the FPGA.
At the end of configuration, the FPGA will enter the startup sequence.
Treat this sequence as a state machine that the FPGA needs to go through
before "waking up". This sequence is where you can set the options of
when you want the DONE pin to go high, the IO tri-state to be released,
etc.
To get through this startup sequence, you'll need to provide clocks.
Generally, when configuring via JTAG, you would select startup clock to
be JTAGCLK since you're already providing TCK. So when configuring with
PROM, you would want to set startup clock to CCLK unless you'll be
seperating providing TCK (JTAGCLK) or even userclock to clock through
the startup sequence.
And as for PROM file generation or ACE file generation, the iMPACT help
topic has been vastly improved in 6.1i. If anything isn't clear, please
do contact the Xilinx Hotline Support.
As far as support for patform flash proms, please make sure you use 5.2i
service pack 3 for file generation.
Regards, Wei
Xilinx Applications
rider wrote:
P
Peter Alfke
Guest
Lorenzo Lutti wrote:
ever invented" in a mere ten minutes...
Peter Alfke
Lorenzo, you must be pretty smart if you can solve the "worst nightmare
ever invented" in a mere ten minutes...
Peter Alfke
P
Plenolo
Guest
Ok, now i am hereHi all i am new in the group, i am a italian student of computer science
and
i have hobbies for electronics, too... so i have using PIC, St6/7
microcontroller, etc.. now my dream is develop some circuit with fpga
(or
similar) and VHLD language. I have just a bit studing (only teorically)
VHDL
in my university, but now i would REALLY program some chip for develop
some
simple and medium project.
I have not money (and i don't want
system, so i would home build some free "programmer" (in-circuit JTAG
???)
how i have do in pass for PIC / St6/7 programmers
You'd be better off on comp.arch.fpga, for the actual hardware
questions - I've crossposted to there and set the followups to go
there also.
)Ok thank i have found ByteblasterMV's datasheet
(http://www.altera.com/literature/ds/dsbytemv.pdf), is it correctly ?
I have found also a PCB and more at http://c.combaret.free.fr/projects.html
and i that it can interest at somebody... and i have found a old article
"Build your own ByteBlaster" from old mirror of "FreeCore Library" at
http://opencollector.org/history/freecore/What%20Altera%20didn't%20tell%20you.htm
but i am also interessed to Xilix cpld and fpga so somebody know if exist
some free programmer like type for Altera chips ?
Thank you very much ALL
ahahahahThank you very much to all friends, and sorry for my very bad and poor
english language
It's better than my Italian!
ciao ciao