Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
Hi, Have a look at http://edif-tc.cs.man.ac.uk They have some software that may be of interest - though I have never used it! Regards, --Phil. P.S.: Utku Ozcan wrote: > EDIF and Tcl are stack-oriented programming languages, so > I think a LISP interface might help you. A text processing LISP > script must be very much compact code than conventional > procedural languages. I think you can catch Tcl code around > which would be in my opinion the best. AFAIK EDIF and Tcl > are LISP variants. Err, I don't think so!Article: 22351
Hi, Have a look at http://edif-tc.cs.man.ac.uk They have some software that may be of interest - though I have never used it! Regards, --Phil. P.S.: Utku Ozcan wrote: > EDIF and Tcl are stack-oriented programming languages, so > I think a LISP interface might help you. A text processing LISP > script must be very much compact code than conventional > procedural languages. I think you can catch Tcl code around > which would be in my opinion the best. AFAIK EDIF and Tcl > are LISP variants. Err, I don't think so!Article: 22352
Hello everyone! Thank you all for your replies!
You all basically suggest the simplest experiments ann of which have
already been done. What I needed is an idea for "something" which requires
couple thousand gates (sponsor's limitation on the simplicity of the demo).
Jim Granville writes:
>
> Candidates are - in order of use in 'new' projects
>
> o Ring oscillator - just a ring of inverters, FreqOut leads to GATE
> delay times
Done, operating frequency 10 GHz in 3.5 um technology! :) What I did
was taking the critical path of a 64-bit CLA (basically 10 inverters +
ORs), connected it in a ring and run it (even measuring BER).
> o Ring Counters - A ring of FF's with one inverter. Shows Divide
> Capability.
I used to hold the world digital processing speed record - 370 GHz
T-flip-flop/frequency divider (in 1.5 um tech), then another one was
designed by a guy in our group running at 770 GHz (submicron
tech). Chains of those were also fabricated for digital
autocorrelator, worked just fine with the top one runnign at
100/something GHz (in 3.5 um).
>
> o Prog Divider - Do a swallow counter, like DIV64/Div65, used in
> frequency synthesisers.
>
> o Delay locked loops - A string of inverters, and a TAP selector, that
> is phase error derived.
>
> o Serial - parallel and parallel-serial converters. This is the engine
> room
> stuff of the 1.25, 2.5. 10GHz fibre optic networks.
Serial/parallel converters have been demonstarted. The problem is that
noone wants to go to liquid He cooling just for fibre mux/demux,
moreover the problem of modulating light with extremely low-power
signals we have on those superconductive chips is definitely not
easy...
>
> None of these need many gates, but all can benefit from FAST devices.
>
> jg.
Peter Alfke writes:
> I suggest a linear feedback shift register counter (LFSR)
> It has very short logic paths. You can clock it at high speed, then read
> out the content by shifting at slow speed ( room temperature).
> The content is an unambiguous indication of the number of received clock
> pulses.
>
> Peter Alfke, Xilinx Applications
> peter@xilinx.com
also,
Illan Glasner writes:
> Hi,
>
> if I understand what you write in the post than your new chip advantage
> for the moment is in its frequnacy.
>
> if so the point of doing intresting algoritum or not seem to me as not
> importent as this is detail, like we say first show me the speed than I
> will find a use for it.
In my post when I wrote "interesting" I took it in quotes, of course
it should not be an interesting algorithm from modern VLSI point of
view ("Hey, here is a cool way to spend 10M gates/chip!" :) ), but it
should be a rather convincing demonstration of digital information
processing with high on-chip rate and low off-chip rates for now.
We have "shown the speed" many times, not it is time to find some
"use"! :)
> therefore a simple counter seem to me to be the simplest example on showing
> how speedy you can get. and since you mention logic limitation you might
> solve it using a LFSR with maybe few output telling it finish 10% 20% etc
> of its psedu random cycle.
>
> have a nice day
>
> Illan
Yes, those shift registers (or something similar) have been done,
basically we use them to test fabrication yield and parameter margins
(running at low speed though). Now for this demo we are designing
something more complex, a simplest microprocessor (with small on-chip
memory to be able to run it "unattended" for couple thousand cycles),
but as a backup project I prefer something with more regular structure
and interconnect than a microprocessor, though still utilizing several
K gates.
By the way, another group here (well, two more people :) ) is
designing like 16-bit oversampling ADC chips with digital filters (run
now at about 15 GHz internal frequency) and DACs (including a real
cool device - voltage amplifier with exactly INTEGER gain - it's a
quantum technology, many weird things are possible). But for
prolitical reasons our demo should not resemble "just" a digital
filter, it should be programmable...
Any further suggestions? :)
Thanks again to all who answered,
Paul
--
("`-''-/").___..--''"`-._ UNIX *is* user-friendly, he is just very
`6_ 6 ) `-. ( ).`-.__.`) picky about who his friends are...
(_Y_.)' ._ ) `._ `. ``-..-' Paul Bunyk, Research Scientist
_..`--'_..-_/ /--'_.' ,'art by (and part-time UN*X sysadm)
(il),-'' (li),' ((!.-' F. Lee http://pbunyk.physics.sunysb.edu/~paul
Article: 22353Attacks that can compromise the key contents often are not all that expensive, and can in fact be done in a pretty low budget operation. Take a look at: http://www.cl.cam.ac.uk/~mgk25/sc99-tamper.pdf for some examples of what is possible. True, it will make it quite a bit harder than copying a bitstream in the open. However, all the would be thief needs is the value of the key so he can program up his own parts with the same key. In this case he is not not trying to reverse engineer the whole design, just the key value. In the case of fused link fuses, the state of the fuses can easily be determined by inspection with a microscope once the lid is off (see the article above for procedures to remove the packaging). My point is that just by having a programmable key on the chip does not provide absolute security. It only provides a barrier that is a bit higher than an open stream. I believe a battery backed up device is much harder to break because there is very little physical evidence left when power is removed, where as a keyed bitstream must have a key stored somewhere. Breaking the encryption in the absence of a key value is also made easier by knowing the format of the bitstream, which is partially provided by such tools as Jbits. If for example, he knows which IOBs are inputs and which are outputs he might be able to use the bitstream segments for those as leverage in breaking the key. "Nicholas C. Weaver" wrote: > In article <39122443.DD973388@fpga-guru.com>, > Ray Andraka <ray@fpga-guru.com> wrote: > > >> Until FPGA's have crypto hardware built in then this type of > >> attack will always exist for all copy protection schemes. > > > >The FPGA would also have to have a unique key in it, and herein lies the > >problem. Even if you did put flash in it with a security bit, it might be > >possible to read the key back out by playing with program voltages etc or by > >de-lidding and inspection. > > However, the barrier for extracting the key from the internal > rom is considerably higher, close to what reverse engineering an ASIC > or antifuse or similar part but a little less than continual battery > backuped SRAM device. > > The other schemes mentioned here are really not very high > barriers, not all that much more then just reverse engineering a board > which was dipped in concrete. > -- > Nicholas C. Weaver nweaver@cs.berkeley.edu -- P.S. Please note the new email address and website url -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 or http://www.fpga-guru.comArticle: 22354
regarding the discovery of the LFSR: Consider the structure of an LFSR: it is a shift register, whose input is a modulo sum of selected taps. The subsequent bits are just time shifted copies of the input bit. Thus after N clocks you know exactly the current state of the LFSR assuming the output comes from the shift register input (if it comes from a different tap it is just time shifted, so your state might be time shifted...not a big deal). If you know the structure of the LFSR, then you just back it up (on paper) to get the initial value (this works because you know the modulo sum and all but one of the inputs to that sum. Since you also know the structure, it is just a matter of solving for the unknown bit. Once that is found then you know the state at time N-1, and you repeat that until you get back to the initial state. If you don't know the structure, then you run N clocks to get to a known state. >>From there each additional clock provides you with the sum from the known state. After N clocks you have N simultaneous equations from which it is easy to solve for the N coefficients (which are 0 or 1). So that is how the LFSR is broken. Encryption adds permutations and "S boxes" to further obfuscate the stream. In DES, the S boxes are 6 input combinatorial functions that select 6 bits each and through a ROM replace one bit value. There is an S box for each bit, so in addition to the LFSR, you get a data dependent permutation of the data stream. Rickman wrote: > I am spending way too much time reading these messages, but I find this > very interesting. So let me play devil's advocate on this. > > david_kessner@my-deja.com wrote: > > > > Ok... Here's my summary, to date, of this LFSR method: > > > > Using a cryptographically strong LFSR, there is no reasonable way to break > > the LFSR by analyzing the random bit stream. This might take more than 64 > > macrocells and more than 20 slices/CLB's. Some might debate this, but it's a > > moot point because... > > Can you define, or better yet give an example of a "cryptographically > strong LFSR"? I do believe it when people have stated that if you know > the structure of a LFSR of length N, it will only take N samples to > determin the initial state. I will also submit to the statement that if > the structure is not known, then it may be possible to determin the > initial state as well as the taps with 2N samples, although I am not > certain you can do this without trying all possiblities which would be > way too expensive for any but the most well funded efforts. But it > certainly makes sense that a LFSR is not truly robust against an > analysis. > > So how do you design a LFSR that can not be easily analyzed? > > > > Ray Andraka <ray@fpga-guru.com> wrote: > > > There is Jbits for 4K/spartan too. > > > > Damn! So we can basically write off this method, and just about any other > > method, that uses current Xilinx chips. (Hey, you killed Kenny! You > > bastard!) > > > > While this method is still applicable to Altera and other FPGA's, there are > > other problems... > > This is a case of ignorance being bliss. I am not aware that Jbits > allows you to reverse engineer a Xilinx bitstream. Is this true or is it > just that Jbits makes it easier to reverse engineer the Xilinx parts in > general and you would still have a major effort in doing so? If you have > to use Jbits to twiddle a bit then you load it into an FPGA and see what > you just changed, then I don't consider this to be an easy way to > reverse engineer a Xilinx configuration bitstream. > > > > Ray also said (paraphrased): > > > With Flash EEPROM or a Flash based CPLD, it might be > > > possible to read the key back out by playing with program voltages etc or by > > > de-lidding and inspection. > > > > I think that this would be ad-hoc at best, and trial and error at worst. But > > none the less, I conceed that this is a potential way to attack and it > > might even be successful. > > Certainly you could conceivably delid a device and examine it with an > electron microscope to analyze it while it is on. I have seen electron > micrographs of circuits in real time. But again I don't consider this to > be in the realm of "easy". I doubt that I would spend as much time and > money on designing the circuit as they would reverse engineering it this > way. > > > > Here's what I currently think the LFSR method is good for: > > > > A simple encryption quality LFSR when implemented in a CPLD > > and Non-Xilinx SRAM based FPGA is sufficent to deter most > > casual pirates. But any professional pirate willing to devote some > > time and money at it will probably be able to break this method in > > a reasonable time frame using one of the previously mentioned > > approaches. In short, I conceed defeat on this one. > > > > Unfortunately, what this shows is that more sophisticated > > encryption would not increase the security given the existance > > of JBits for all Xilinx parts of interest and given the vulnerability > > of Flash based CPLD's (and probably uC's as well). > > > > Oh well. It was a nice try... :( > > Others have indicated that the LFSR is less robust and I feel that the > Xilinx design and the CPLD (or micro in my case) are more robust than my > requirements. So depending on just how hard it is to attack the LFSR > initial state, we may need a more robust algorithm. > > > > And another thing... Someone mentioned using a free-running > > oscilator (made from an inverter fed back into itself) as a source > > for random numbers. Unfortunately this doesn't work. It works > > in the simulators, but not in real devices. If you put two of these > > oscilators on the same FPGA (and nothing else) they tend to > > lock to eachother and will eventually will be in sync and remain > > in sync. With just one of these oscilators on a full FPGA, the > > osc will tend to lock to some other source of noise in the system > > which will make the random numbers highly correlated to what's > > going on in the FPGA-- not random at all. > > I am not convinced that this is really a problem. If the two oscillators > lock to some ratio on a given board, that will not say that they will > allways lock at that ratio on every board. The random numbers only have > to produce a pattern of numbers that is not repeatable on powerup. Even > if the two oscillators are locked, that will not guarantee that they > will produce the same result every time like a computer program would. > Remember that the non-crystal oscillator will be voltage, temperature > and process dependant as well. > > > > Using the on board temperature sensor doesn't work either-- > > at least not for security uses. That's because the temp > > sensor requires that the signals be ran outside the chip. > > If they are outside the chip then they are vulerable to attack. > > For instance, someone could just ground those signals and > > force the random number generator to always output zero > > (or one, or whatever). > > > > David Kessner > > davidk@free-ip.com > > > > Sent via Deja.com http://www.deja.com/ > > Before you buy. > > I would be willing to bet that a form of stimulus, response approach > would be the most resistant to attack. The FPGA uses the non-repeated > (as opposed to PRNG) generator from the free running oscillator to > stimulate the Key Chip (since it may be a micro rather than a CPLD). The > Key Chip then returns a result based on some processing with the LFSR. > This can be duplicated in the FPGA with different initial conditions for > different designs/customers as you choose. The FPGA would only stimulate > the Key Chip say a hundred times a second. If the Key Chip is stimulated > more often, it shuts down until power is removed. > > This would be resistant to copying the key bitstream since the stimulus > will be different for different boards. Analysis would not work since > the data can only be dragged out of the Key Chip at a very low data > rate. Since the direct output of the LFSR is not observed, the LFSR > initial state can not be analyzed. > > Does this cover all the bases? > > -- > > Rick Collins > > rick.collins@XYarius.com > > remove the XY to email me. > > Arius - A Signal Processing Solutions Company > Specializing in DSP and FPGA design > > Arius > 4 King Ave > Frederick, MD 21701-3110 > 301-682-7772 Voice > 301-682-7666 FAX > > Internet URL http://www.arius.com -- P.S. Please note the new email address and website url -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 or http://www.fpga-guru.comArticle: 22355
(I would have just mailed this, but the mail bounced)
----- Transcript of session follows -----
554 MX list for fpga-guru.com. points back to pop3.ids.net
554 <ray@fpga-guru.com>... Local configuration error
--OAA16864.957549960/pop3.ids.net
In article <39130507.8AFDFC4A@fpga-guru.com> you write:
>Attacks that can compromise the key contents often are not all that
>expensive, and can in fact be done in a pretty low budget operation.
{Ref munched}
Agreed, my point is that it is however, considerably harder to
attack then the other, two chip schemes mentioned and the like, where
an in-the-clear bitfile can be directly attacked to remove the
protection code.
>Breaking the encryption in the absence of a key value is also made
>easier by knowing the format of the bitstream, which is partially
>provided by such tools as Jbits. If for example, he knows which IOBs
>are inputs and which are outputs he might be able to use the
>bitstream segments for those as leverage in breaking the key.
For a GOOD encryption algorithm and a good chaining (eg, CFB
chaining), this is NOT a significant help, as this is just simply some
known plaintext for a known plaintext attack. And, if you are going
to convince the vendors to do it at all, you are going to need to
convince the vendors to implement a good, standard block cypher so it
can be used for purposes other than just encrypting bitfiles anyway.
AES is coming, and everyone WILL be using AES.
--
Nicholas C. Weaver nweaver@cs.berkeley.edu
Article: 22356
Hi;
Are you programming in express mode or serially? in express mode I had
a problem with the xilinx implementation of the FPGA. To solve this i
needed to modify the bitgen.ut file and run it from the dos prompt. I was
using foundation 2.1i, I am not sure if they have a patch to fix this or
not, but you should be able to find the solution on the xilinx web page.
wes
e97bjli@thn.htu.se wrote in message <8es15h$vpt$1@nnrp1.deja.com>...
>Hi.
>
>I have a problem with my FPGA device (Spartan XCS10 PC84)
>
>When I download my program to the device via JTAG (Parallel cable III),
>The programming tool write "programming successfully".
>
>But when I connect my oscilloscop to the pins of the device, all pins
>except ground are high ( '1' ).
>
>I dont know what to do.
>
>ALL Vcc are connected to ground via 0.1 uF capacitor.
>
>INIT is connected to Vcc via 4700 ohm resistor.
>
>Mode is unconnected. (because we use an external oscillator)
>
>TCK,TDI,TMS,TDO,Vcc,GND, and the external clock are connected from the
>JTAG according to the following:
>TCK to pin 16
>TDI to pin 15
>TMS to pin 17
>TDO to pin 75
>Vcc to pin 2, 11, 22, 33, 42, 54, 63, 74
>GND to pin 1, 12, 21, 31, 43, 52, 64, 76
>external clock to pin 35.
>
>My code at the bottum of the mail:
>
>Thankful for help
>
>
>Björn Lindegren
>
>
>library IEEE;
>use IEEE.std_logic_1164.all;
>
>entity sampel is
> port (
> clk,reset: in STD_LOGIC;
> input: in STD_LOGIC_VECTOR (7 downto 0);
> output: out STD_LOGIC_VECTOR (7 downto 0);
> Q2 : out STD_ULOGIC;
> Q3 : out STD_ULOGIC;
> Q1Q4 : out STD_ULOGIC;
> DONEIN : out STD_ULOGIC;
> --GSR : in STD_ULOGIC;
> GTS_IN : in STD_ULOGIC;
> cs: out STD_LOGIC
> --int: inout STD_LOGIC
> );
>end sampel;
>
>architecture sampel_arch of sampel is
>
> signal sampelcounter: integer range 0 to 15;
>
> component STARTUP
> port(
> Q2 : out STD_ULOGIC := 'H';
> Q3 : out STD_ULOGIC := 'H';
> Q1Q4 : out STD_ULOGIC := 'H';
> DONEIN : out STD_ULOGIC := 'H';
> GSR : in STD_ULOGIC;
> GTS : in STD_ULOGIC;
> CLK : in STD_ULOGIC);
>end component;
>
>begin
>
> U1: STARTUP PORT MAP( GSR=>reset,clk=>CLK,Q2=>Q2, Q3=>Q3, Q1Q4=>Q1Q4,
>DONEIN=>DONEIN,GTS=>GTS_IN);
>
> sampelprocess: process(reset,clk)
>
> begin
>
> if reset ='1' then
>
> output<=(others=>'0');
>
> cs<='1';
>
> elsif clk='1' and clk'event then
>
> if sampelcounter=0 or sampelcounter=5 then
>
> cs<='0';
>
> elsif sampelcounter=10 then
>
> cs<='1';
> output<=input;
>
>
> end if;
>
> end if;
> end process sampelprocess;
>
>sampelcount: process(reset,clk)
>
> begin
>
> if reset ='1' then
>
> sampelcounter<=0;
>
> elsif clk='1' and clk'event then
>
> sampelcounter<=sampelcounter+1;
>
> if sampelcounter=11 then
>
> sampelcounter<=0;
>
> end if;
> end if;
>
> end process sampelcount;
>
>end sampel_arch;
>
>
>
>
>
>
>Sent via Deja.com http://www.deja.com/
>Before you buy.
>
Article: 22357Hi, I use this all the time using Viewlogic schematic capture. I have an OBUFT driving IOPADs. In parallel with that I have an IBUF directly driving a BUFT. The input to the OBUFT is connected to the output of the BUFT so that internally its one bus. It only splits briefly to either drive the I/O pads or to receive from the pads. Each of these buffers can be 8 wide or 16 wide, etc. Good Luck Sent via Deja.com http://www.deja.com/ Before you buy.Article: 22358
Phil Endecott <phil_endecott@spamcop.net> writes: > Hi, > > Have a look at > > http://edif-tc.cs.man.ac.uk > > They have some software that may be of interest - though I > have never used it! > Thanks for the hint, it looks ok at first sight, but unfortunately their 'free' tools are free as in free beer and not free as in free speech (i.e., no open source). Most software at that site is pay-ware and everything is binary only for NT and Solaris (not even Linux). What I was actually looking for was some library that parses edif (as generic lisp) and creates some tree structure for C, Perl or similar. thanks anyway, chm. -- cmautner@ - Christian Mautner utanet.at - Vienna/Austria/EuropeArticle: 22359
In article <39126715.7C1C7338@utc.fr>,
Sebastien Favard (Gordh) <Sebastien.Favard@utc.fr> wrote:
>Philip Freidin wrote:
>
>> If you really have ALL the input bits appearing onthe DOUT, this is
>> definitely not good. The data on the DOUT pin will be a delayed by 1
>> cycle version of the data on the DIN pin, but ONLY for the duration of
>> the header (40 bits). After the header, the DOUT pin should be high for
>> the duration of the bitstream, and then reverts to echoing the DIN data
>> to load down stream parts. In a single chip situation, there is no
>> downstream devices, so the device will complete and then go DONE.
>
>Yes I have read all data after the write cycle... But the DOUT pin hold the
>bit ! In fact if you see the databook XC5200 p7-114 you could see the
>chronogram with all data bit reported after the write cycle on the DOUT pin
>%-(
>I have never read that is only for the header sequence...
Here's how it works, ( I am absolutely SURE it works this way) :
Assume several chips in serial daisy chain mode (can be a mix of 3K, 4K,
XC5200, with some constraints, which are not relevant to this discussion),
and the config data is coming from a processor that is bit banging the
CCLK and DIN signal. See fig 28 on page 114, and replace the 5200 on the
left with the processor that is the source of the data.
1) The Program pin is pulled down, telling all chips to get ready to
be configured. The chips clear their memory, and reset a counter
called the length counter. This counter counts CCLK rising edges,
which is why a system with a free running CCLK will never work.
2) After the memory is cleared ( may take upto a milisecond on large
devices) the INIT line goes high (Must have a pullup resistor on it)
indicating the device is ready for configuration. In a multi chip
situation, you must wait for ALL init lines to go high. It is easiest
to just join them together as show in fig 28, and the wired AND
function wont let the resistor pull the init line high until all chips
stop pulling it low.
3) No sooner than 5 uS after INIT goes high, you can supply the first bit
of configuration (which will be a '1'). see timing diag on page 7-119
and look at just CCLK and INIT. In serial slave mode, the first data
bit in occurs with the first rising edge of CCLK. The length counter
starts counting CCLK rising edges, which is why a free running CCLK
wont work.
4) The header is sent 1 bit at a time, as per table 11 on page 1-107.
At least the first 12 bits (coresponding to the first 12 rising
edges of CCLK) must ALL be '1' bits.
Then there is the preamble which is the bit sequence:
'0' , '0' , '1' , '0'
This tells the FPGA that the next 24 bits are the total bitstream
length, and they are sent MSB first.
12 x '1' + '0010' + 24 len bits => 40 bits
Then there are at least 8 fill bits, ALL '1', can be more, but
that is what the software generates. If you changed the number
of bits here, you would also have to recalculate the length count.
Then there is the start byte. The data frame actually starts with
the first '0' bit. The 7 leading '1' bits are ignored, just like
the preceding 8 fill bits.
The chip then starts configuring using the supplied data. It is
keeping track of when it is full, as well as the number of CCLK
rising edges are occuring.
So whats happened on DOUT???
After Program has gone low, the device cleared itself, and INIT went high,
the data supplied on DIN was copied to DOUT. Data is sampled on DIN on the
rising edge of CCLK, and is changed on the DOUT pin on the Falling edge of
CCLK. This makes for very easy board level CCLK distribution. The all the
chips in the daisy chain will initially see a string of '1' bits. They
ignore them, except for counting the CCLK cycles. Eventually the first
chip sees the preamble code '0010' and it starts to record the length
count valu of 24 bits. It continues to copy DIN to DOUT while this is
hapening. The down stream chips each see the length count in turn, each
one receiving it with an additional 1 clock cycle delay. This doesn't
matter, because the length count that is loaded from the bitstream is
going to be compared to the counter that has been counting CCLK cycles
since the start of configuration, and the arrival time of the length
count does not effect this.
Once the first chip has received the length count it stops copying DIN to
DOUT, and output '1' bits while consuming the incoming DIN data for its
own configuration. The down stream FPGAs just see a very long stream of
'1' bits after the header, which they ignore.
This continues until the first chip is full, at which time it restarts
copying DIN to DOUT. This pass through data is used to configure
successive chips in the daisy chain the same way.
Once the device is full, it waits for the length count value (loaded from
the header) to match the CCLK counter. See fig 26 on page 7-112, AND gate
at far left. This starts the startup logic, which after a few more clock
takes the chip DONE and lets it run. This is why you need to supply a few
more clocks than the length of the bitstream, to cycle this state machine.
See also the figure 22 on page 7-21
============
So, when you say you see ALL of the bitstream on DOUT, I know something
is wrong. There are only three ways I know of that this can happen:
1) DIN and DOUT are shorted together
2) The chip has not yet seen the '0010' code and thinks it is still
copying the header
3) The chip thinks it is FULL, but the length count has not yet matched
>
>But if you're sure, perhaps the header is not correctly read byt the FPGA and
>all bits are reported on the DOUT pin :(
I am absolutely sure. Look at the header coming out of DOUT. It should
look like:
1 1 1 1 1 1 1 1 1 1 1 1 0 0 1 0 H H H H H H H H
H H H H H H H H H H H H H H H H 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1
>> Is the config clock clean, both rising and falling edges, check
>> with at least a 300MHz scope.
>
>hum.... I must check it with a oscilloscope but this signal has already test
>my board with others latchs (just for tests) so...
Although CCLK is a fairly slow clock, the config logic contains some very
fast logic, and glitches on the CCLK, including crappy edges due to poor
termination, can cause double clocking, etc.
>> Are you changing DIN data when the CCLK clock edge rises, You
>> shouldn't
>Year... DIN is at least 60ns set before the CCLK rising edge (20ns is the
>minimal setup time)
This should be OK.
>> An unloaded HDC could be at 5V, but LDC should be near ground. What do you
>> have connected to it?
>>
>
>Just a volt-tester :( It's really strange to see 1.1V on the LDC/ line !
I agree. Check for shorts, a pull up resistor?, dead chip, dead volt-tester?
Good luck,
Philip Freidin
Article: 22360
"Sebastien Favard (Gordh)" <Sebastien.Favard@utc.fr> writes:
> > You should post your bitgen.ut file, then it would be easier for us to
> > help you. Even if you use the GUI, there is a bitget.ut file created.
> >
>
> I don't known the ucf format :( I use Leonardo Spectrum on Unix to create a
> edif or xnf... netlist. After I use Alliance on UNIX to translate the netlist
> in ncf format and eventually generate a bitstream.
> How format can I post ? Or perhaps the VHDL design ? It's just a VERY small
> design to test the configuration process on the FPGA so...
I said .ut, and not .ucf. Do a 'find -name "*.ut" -print' and you
should find it, Alliance creates it for you. (I guess this is in the
Unix version just as it is in NT)
But it seems, as Rick said in his posting, that you just mistakenly
selected USERCLK as your startup clock. This would mean that you want
the startup sequence "done, activating output, dropping GSR" to be
synchronous to some clock other than the CCLK. If you don't have a
good reason for that, it is not necessary
> Incredible> Why I must instantiate a StartUp component on my design VHDL ? I
> think really that you have right but it's not really logical. In fact, the
> design FPGA represents only (for me !) the description of comportment
> AFTER the configuration process. So why I must specify the configuration
> process "component" in the design ?
That's the feature. If you want it simple, select CCLK; if you know
what you do, you have to do something more complicated.
> LIBRARY IEEE;
> USE IEEE.STD_LOGIC_1164.ALL;
> LIBRARY exemplar;
> USE exemplar.exemplar_1164.ALL;
>
>
> ENTITY FPGA IS
> PORT (
> Clock_i : IN STD_LOGIC;
> Reset_ib : IN STD_LOGIC;
> CCLK_i : IN STD_LOGIC;
>
> CS_ib : IN STD_LOGIC;
> RdWr_i : IN STD_LOGIC;
> Data_io : INOUT STD_LOGIC_VECTOR(7 downto 0)
>
> );
>
>
> -- Pin Location --
> ------------------
>
> ATTRIBUTE PIN_NUMBER : STRING;
> ATTRIBUTE PIN_NUMBER OF Clock_i : SIGNAL IS "P35";
> ATTRIBUTE PIN_NUMBER OF CCLK_i : SIGNAL IS "P73";
>
> ATTRIBUTE PIN_NUMBER OF Reset_ib : SIGNAL IS "P84";
>
> ATTRIBUTE PIN_NUMBER OF CS_ib : SIGNAL IS "P13";
> ATTRIBUTE PIN_NUMBER OF RdWr_i : SIGNAL IS "P47";
> ATTRIBUTE ARRAY_PIN_NUMBER OF Data_io : SIGNAL IS
> ("P56","P58","P59","P61","P65","P67","P69","P71");
>
>
> -- Global CLK --
> ----------------
>
> ATTRIBUTE BUFFER_SIG OF Clock_i : SIGNAL IS "BUFG";
> ATTRIBUTE BUFFER_SIG OF CS_ib : SIGNAL IS "BUFG";
>
>
> -- CLOCK definition --
> ----------------------
> ATTRIBUTE CLOCK_CYCLE OF Clock_i : SIGNAL IS 83ns; -- 12 MHz (8 MHz =>
> 125ns)
> --ATTRIBUTE CLOCK_OFFSET OF Clock_i : SIGNAL IS ns;
> --ATTRIBUTE PULSE_WIDTH OF Clock_i : SIGNAL IS ns;
> --ATTRIBUTE ARRIVAL_TIME OF Clock_i : SIGNAL IS ns;
>
>
> END FPGA;
>
> ARCHITECTURE XC5200 OF FPGA IS
> SIGNAL Dummy1,Dummy2,Dummy3,Dummy4 : STD_LOGIC;
>
> SIGNAL Reset : STD_LOGIC;
>
> SIGNAL RegTmp: STD_LOGIC;
>
> COMPONENT STARTBUF
> PORT (GSRin, GTSin, CLKin : IN STD_LOGIC;
> GSRout, GTSout, DONEinout, Q1Q4out, Q2out, Q3out : OUT STD_LOGIC);
> END COMPONENT;
>
> BEGIN
>
> StartComponent:STARTBUF port map (GSRin => Reset_ib,
> GTSin => '0',
> CLKin => CCLK_i,
> GSRout => Reset,
> DONEinout => Dummy4,
> Q1Q4out => Dummy1,
> Q2out => Dummy2,
> Q3out => Dummy3);
What is STARTBUF? Now I'm confused. Is this some exemplar feature? I'm
using FPGA express, and xilinx 4k family. If would use STARTUP in this
design I would just do
COMPONENT STARTUP
PORT ( gsr : IN STD_LOGIC;
clk : IN STD_LOGIC);
END COMPONENT;
and:
m_startup: STARTUP PORT MAP( clk => Clock_i, gsr => reset );
(but my reset is an asynchronous reset always, just to define the
startup state)
>
> PROCESS (Clock_i)
> BEGIN
> IF Rising_Edge(Clock_i) THEN
> IF (CS_ib = '0') THEN
> IF (Reset = '0') THEN
> RegTmp <= '0';
> ELSE
> IF (RdWr_i = '1') THEN
> Data_io <= "0101010" & RegTmp;
> ELSE
> Data_io <= (others => 'Z');
> END IF;
> END IF;
> END IF;
> END IF;
> END PROCESS;
>
>
> END XC5200;
>
--
cmautner@ - Christian Mautner
utanet.at - Vienna/Austria/Europe
Article: 22361Rickman <spamgoeshere4@yahoo.com> writes: > I think what is being said is that you must have mistakenly selected the > USERCLK for the Startupclk in the GUI. There in normally not a strong > reason for changing the default from CCLK to USERCLK. If you do have a > reason for this change, then you need to provide a USERCLK to the > StartUp component in your design. Otherwise just change it back to CCLK! > I'm using the USERCLK (being the system clock of the fully synchronous design) always at the startup clock. I believe that, if CCLK is used, timing constraints might be violated (since CCLK is asynchronous to the system clock) at startup. Is this more carful than necessary? chm. -- cmautner@ - Christian Mautner utanet.at - Vienna/Austria/EuropeArticle: 22362
Utku Ozcan <ozcan@netas.com.tr> writes: > EDIF and Tcl are stack-oriented programming languages, so > I think a LISP interface might help you. A text processing LISP > script must be very much compact code than conventional > procedural languages. I think you can catch Tcl code around > which would be in my opinion the best. AFAIK EDIF and Tcl > are LISP variants. Well, sure, EDIF is lisp. But Tcl is not. And both of them are not stack oriented. And Tcl is just-another wimpy procedural scripting languge, on the level of about BASIC. Sorry if this sounds flaming, it surely is not. I just didn't want to let this posting un-answered. And I'm wondering why Tcl is so popular (FPGA express, leonardo, Quartus, and a lot more). thanks, chm. -- cmautner@ - Christian Mautner utanet.at - Vienna/Austria/EuropeArticle: 22363
Christian Mautner wrote: > just installed FPGA express 3.4 today, and had to accept that now the > step from XNF to EDIF has been taken. So I guess I'll have to dump my > xnf-parsing perl scripts. (Moan), this is not good news at all. I don't care for the Aldec schematic editor, in a big way! I have Protel, and they can output XNF, EDIF, VHDL and a host of other formats. But, the only format that I have seen work is XNF. The EDIF and VHDL files out of Protel are NOT acceptable to the Xilinx tools (and probably anyone else). So, there's no way to make the new tools accept an XNF? If not, is there an XNF to EDIF translator? (I guess that would be XNF2EDF.EXE or something like that.) Thanks, JonArticle: 22364
FPGA gurus,
I am programming a Virtex XC400, after synthesizing
with Synplify. Synplify claims to be finding my three clocks
requiring global buffers (two input clocks, one internal.)
I am hardwiring the locations of the two input clocks to pins
89 and 92 (which of course are global buffer pins).
I am having problems putting a normal (non-clock) input
on one of the global buffer input pins that I am not using
for a global buffer (pin 213). The error message from the mapper
follows.
Running directed packing...
ERROR:xvkpu:19 - The symbol XTAL1200K.PAD failed to join a regular
I/O
component as required. The symbol has a constraint (LOC=P213)
that specifies
an illegal physical site for the component. Please correct the
constraint
value.
Problem encountered during the packing phase.
1. Shouldn't I be able to use global buffer pins for inputs
that do NOT require the global buffer? Recall that synplify
is instantiating the buffers for me.
2. Also, is there a way for me to find out which of the four buffers
are being used for the internal nets requiring clock buffers?
I can't find it in the logs.
Thanks,
Matt
Article: 22365I think you are confused about the meaning of the StartupClk:UserClk option. Please examine Figure 26 on page 7-112 of the 1999 Xilinx Data Book. There is a 5 stage FF chain which controls the final startup sequence of the device. The StartupClk:UserClk option indicates that you want the last 4 FFs to be clocked by a signal connected to the clock pin on the startup component. The default option of StartupClk:CClk indicates that these FFs should be clocked by the CCLK signal. The first FF is always clocked by CCLK. Please note the selection of CCLK as the clock source has no bearing on whether the CCLK is generated by the FPGA (the Master modes) or by an external source such as an SPROM or microprocessor (the Slave modes). The choice of the source for the startup clock is completely independent of the configuration mode. Mark --- / 7\'7 Mark Proctor - Sr. Software Engineer \ \ Xilinx Boulder / / 2300 55th St. Boulder, CO 80301 \_\/.\Article: 22366
Catalin Baetoniu wrote: > > Hi Jim, > > Jim Granville wrote: > > > a@z.com wrote: > > > > > > Hi David, > > > > > > I do not think your idea will work because reverse engineering the CPLD > > > is realy easy. All you need to do is capture a sequence of 2*n bits, > > > where n is the size of your LFSR. > > > > True, but who says you have to code a LFSR in the CPLD, and use > > obvious LD.CLK.DATA pins. > > Well, David Kessner does. He proposed at > http://www.free-ip.com/copyprotection.html a CPLD key based on a 36-bit LFSR > and asked for comments. > > > That's why I mentioned the ATF750, ( 24 pin CPLD ) with either > > edge clock, on any cell, you can create something that defies > > modeling - mixing PROM and Sequential state logic also makes > > stream analysis very hard. > > Then add cross coupled clock enables, and async clocks... > > David also makes the point - and I think he is right - that the protection > should be strong enough by design so that its internal structure can be made > public without compromising the key. A secret design is a weak design is a > basic cryptography concept which applies in this case too. There are really two levels under discussion. A public key is certainly the best, but that excludes a CPLD. The challenge is to secure, without the security costing $$$. > Nothing that is made with digital logic defies modeling - no matter how > clever your design is (clock enables, async clocks, etc.) it is still a > finite state machine and can be modeled as such. What matters is observabilty > of the hidden state and controllability (if you have inputs). Adding inputs > (clocks, enables, data in) might be a bad idea because you make the system > more controllable - using these inputs I can bring your system to a large > number of known states and explore the state space from each point. Maybe, but you need to bring it to ALL used States, to get a 100% coverage data file. This data file will be GB in size, and will then need some serious compression analysers, to try and create the same I/O, by discarding the 'not relevent' states. On this 'lock', ANY pin _might_ be ( currently ) a clock, and the data-history on any other pin(s) _might_ be being stored, for a ROM table jump... Maybe this is all do-able, given enough time, and SW, but the resulting extracted file, and device it has to run in, will be _huge_ compared with the starting CPLD. Any data file that is not 100% state space coverage is useless, and HOW does the hacker know they have achieved 100.0% ? What I am talking about is more complex than LFSR, but still SPLD doable. A LFSR is really just a giant ring counter, and any state only jumps to the next, with a single clock, and data. Add any sort of time-element, even a humble monostable, the complexity goes up again.. > What you think is your strong point might turn out to be your Achilles' heel. From a > controllability point of view, the ideal system would have no inputs at all, > as David proposed, an uncontrollable system. The problem with his idea is > that his state machine (a 36-bit LFSR) is completely and easily observable - > all you need is 72 consecutive output bits to find out the complete state > space map (the LFSR taps) and the initial state. With 72 macrocells there > must be a lot of finite state machines with no inputs If it has no inputs, how does the FPGA key track the CPLD key ? > that produce an output sequence such that you need to acquire too many > bits to completely observe > the system state, even if you know the structure of the state machine and the > only unknown is the initial state. No need for fancy hidden tricks, just use > the right design and make it big enough. Then make it _public_ and challenge > everyone to break it. If a lot of people try and nobody succeeds then _maybe_ > you have a winner. > > Catalin A key to limited resource cyphers is to confuse the opponent. I believe the USA did this in WW II, using an obscure, non written, native language dialect. The 3rd Reich chose German. Which you choose also depends on what you seek to prevent/protect - Slavish copying - Counterfeit sales - Data of national security relevence - jgArticle: 22367
On 04 May 2000 18:54:46 -0400, Paul Bunyk <paul@pbunyk.physics.sunysb.edu> wrote: > >Hello, everyone! > >I'm developing a new (at least pretty much unheard of) supercondicting >logic family (RSFQ) and I'd like to make a demo chip implementing some >kind of regular programmable logic function similar to FPGAs/CPLDs. > >I wonder if someone can point me to the information about the earliest >and simplest FPGA structures which I can try to implement. [...] >Another limitation is that the structure should have relatively short >connections on the chip, preferably arranged in systolic array-like >pattern (it takes time comparable to the 50 ps clock cycle to pass a >signal across the chip just due to the finite speed of light in >on-chip microstrips). At which point it sounds to me like the Xilinx XC6200 FPGA family, or maybe the old Pilkington designs. These were fine-grained, where each cell was a very small unit with only a few inputs and a single flip flop. They didn't offer great performance because they didn't have anything like hard-wired carry chains. And they didn't clock at 20GHz! But (in the XC6200) each cell was relatively simple and the routing information was published and looked simple and regular (as far as I could see) ... and most important of all, the bitstream format was open and fully published! Some design tools are still floating around (search for VELAB on the Xilinx website ... and I think ETH Zurich developed some). Good luck with an exciting sounding project! - BrianArticle: 22368
Hi Jim, The context discussed here is that of an open core protection scheme for FPGAs. Something that it is posted on a www page for all to see (including the potential copier) but is still very hard to break if you do not know the key. While your approach is valid for a do it your self protection good for your own use (if you really trust it) it is not good for what we are discussing here. If I will use your system I want to be sure it works and you will have to make it public. All your hidden tricks lose their advantage then. The system must be strong by design not by hiding information. It doesn't have to be triple DES or PGP but it must be hard enough, at least as hard as reverse engineering the FPGA bitstream. I would like to propose the following system: A 48-bit LFSR with the position of the taps public is loaded at reset with a secret initial value. The 48-bit state is broken into 6 groups of 4 bits which pass trough six look-up tables. The content of the look-up tables is also secret and is fixed (your key is then 144 bits). The six look-up table outputs are xored together and are the only signal output by the CPLD. There is no input except for the clock and the reset. The output of the CPLD is both long enough to be captured, stored and played back in a copy of the system and hopefully complex enough to defy analysis. Everything should fit in a 72 macrocell CPLD and in less than 10 FPGA CLBs. If anybody wants to try to break this I can set up a challenge test. Catalin Jim Granville wrote: > Catalin Baetoniu wrote: > > > > Hi Jim, > > > > Jim Granville wrote: > > > > > a@z.com wrote: > > > > > > > > Hi David, > > > > > > > > I do not think your idea will work because reverse engineering the CPLD > > > > is realy easy. All you need to do is capture a sequence of 2*n bits, > > > > where n is the size of your LFSR. > > > > > > True, but who says you have to code a LFSR in the CPLD, and use > > > obvious LD.CLK.DATA pins. > > > > Well, David Kessner does. He proposed at > > http://www.free-ip.com/copyprotection.html a CPLD key based on a 36-bit LFSR > > and asked for comments. > > > > > That's why I mentioned the ATF750, ( 24 pin CPLD ) with either > > > edge clock, on any cell, you can create something that defies > > > modeling - mixing PROM and Sequential state logic also makes > > > stream analysis very hard. > > > Then add cross coupled clock enables, and async clocks... > > > > David also makes the point - and I think he is right - that the protection > > should be strong enough by design so that its internal structure can be made > > public without compromising the key. A secret design is a weak design is a > > basic cryptography concept which applies in this case too. > > There are really two levels under discussion. A public key is certainly > the best, but that excludes a CPLD. The challenge is to secure, without > the security costing $$$. > > > Nothing that is made with digital logic defies modeling - no matter how > > clever your design is (clock enables, async clocks, etc.) it is still a > > finite state machine and can be modeled as such. What matters is observabilty > > of the hidden state and controllability (if you have inputs). Adding inputs > > (clocks, enables, data in) might be a bad idea because you make the system > > more controllable - using these inputs I can bring your system to a large > > number of known states and explore the state space from each point. > > Maybe, but you need to bring it to ALL used States, to get a 100% > coverage > data file. This data file will be GB in size, and will then need some > serious compression analysers, to try and create the same I/O, by > discarding the 'not relevent' states. > > On this 'lock', ANY pin _might_ be ( currently ) a clock, and > the data-history on any other pin(s) _might_ be being stored, > for a ROM table jump... > > Maybe this is all do-able, given enough time, and SW, but the resulting > extracted file, and device it has to run in, will be _huge_ compared > with the starting CPLD. > > Any data file that is not 100% state space coverage is useless, and HOW > does the hacker know they have achieved 100.0% ? > > What I am talking about is more complex than LFSR, but still SPLD > doable. > A LFSR is really just a giant ring counter, and any state only jumps to > the > next, with a single clock, and data. > > Add any sort of time-element, even a humble monostable, the complexity > goes up > again.. > > > What you think is your strong point might turn out to be your Achilles' heel. From a > > controllability point of view, the ideal system would have no inputs at all, > > as David proposed, an uncontrollable system. The problem with his idea is > > that his state machine (a 36-bit LFSR) is completely and easily observable - > > all you need is 72 consecutive output bits to find out the complete state > > space map (the LFSR taps) and the initial state. With 72 macrocells there > > must be a lot of finite state machines with no inputs > > If it has no inputs, how does the FPGA key track the CPLD key ? > > > that produce an output sequence such that you need to acquire too many > > bits to completely observe > > the system state, even if you know the structure of the state machine and the > > only unknown is the initial state. No need for fancy hidden tricks, just use > > the right design and make it big enough. Then make it _public_ and challenge > > everyone to break it. If a lot of people try and nobody succeeds then _maybe_ > > you have a winner. > > > > Catalin > > A key to limited resource cyphers is to confuse the opponent. > I believe the USA did this in WW II, using an obscure, non written, > native > language dialect. The 3rd Reich chose German. > > Which you choose also depends on what you seek to prevent/protect > - Slavish copying > - Counterfeit sales > - Data of national security relevence > > - jgArticle: 22369
Paul Bunyk <paul@pbunyk.physics.sunysb.edu> wrote: > Hello everyone! Thank you all for your replies! > You all basically suggest the simplest experiments ann of which > have already been done. What I needed is an idea for "something" > which requires couple thousand gates (sponsor's limitation on the > simplicity of the demo). Seems to me then (you having mentioned FPGA's/FPLD's) is that what you might want would be to implement a PAL of this complexity level. Something like a 22V10 equivalent, with SRAM cells (you DO have SRAM cells in this technology?) to control the programming pattern, might add up to a couple thousand gates. But this might not meet your highly serial/systolic requirement. But it would be pretty testable (i.e. good coverage without wasting gates on design-for-testability features). Alternatively, and this would be more systolic, you could do some signal processing function -- say, a correlator/sync detector, or a Reed-Solomin encoder or viterbi decoder or something. Small examples of these are only a couple thousand gates. SteveArticle: 22370
Mark Proctor wrote: > I think you are confused about the meaning of the StartupClk:UserClk option. > Please examine Figure 26 on page 7-112 of the 1999 Xilinx Data Book. There is > a 5 stage FF chain which controls the final startup sequence of the device. The > StartupClk:UserClk option indicates that you want the last 4 FFs to be clocked > by a signal connected to the clock pin on the startup component. The default > option of StartupClk:CClk indicates that these FFs should be clocked by the > CCLK signal. The first FF is always clocked by CCLK. Yes, you've right Mark. I thinked that my problem was the source CLK but in fact it's false. In fact, I try to configurate my XC5200 but when I send all bits in Serial Slave Mode, I can read them in the DOUT pin. But after a various N bits sended, the chip pull down the init/ signal :( So with this problem, I have tried to put another StartUpClk but in fact it's really dummy because this step is AFTER the configuration process step. Have you an idea about my problem ? Another very strange thing is the chip pull up correctly the HDC signal at 5V, but LDC/ is near 1.1V !!! Have I an electrical power problem ? Thanks for all, best regards Sebastien Favard - UTC Research CenterArticle: 22371
I said .ut, and not .ucf. Do a 'find -name "*.ut" -print' and you
should find it, Alliance creates it for you. (I guess this is in the
Unix version just as it is in NT)
Yes sorry, .ut :) But I have not find .ut file !
But it seems, as Rick said in his posting, that you just mistakenly
selected USERCLK as your startup clock. This would mean that you want
the startup sequence "done, activating output, dropping GSR" to be
synchronous to some clock other than the CCLK. If you don't have a
good reason for that, it is not necessary
OK, I have understand the objectif of the StartUp sequence. But in fact my
problem is before this step: configuration process :(
> StartComponent:STARTBUF port map (GSRin => Reset_ib,
> GTSin => '0',
> CLKin => CCLK_i,
> GSRout => Reset,
> DONEinout => Dummy4,
> Q1Q4out => Dummy1,
> Q2out => Dummy2,
> Q3out => Dummy3);
What is STARTBUF? Now I'm confused. Is this some exemplar feature? I'm
using FPGA express, and xilinx 4k family. If would use STARTUP in this
design I would just do
COMPONENT STARTUP
PORT ( gsr : IN STD_LOGIC;
clk : IN STD_LOGIC);
END COMPONENT;
In the XC5200 family, I have find this component in the product specification
p7-90.
Thanks,
Article: 22372While I appreciate that you are thrilled about the possibilities of RSFQ technology, I think that your initial request was unfortunately phrased, leading people to waste their valuable time supplying simple structure ideas... O.K., so you REALLY need to use a couple thousand femtosecond gates in an interesting way, not really having anything to do with FPGAS. Given the high on/off chip speed ratio, prime number factorization or maybe high speed "ILOVEYOU" pattern matching might do, though to really wow the suits you will have to boot Apple II Basic and run VisiCalc :) regards, tom Paul Bunyk wrote: > > Hello everyone! Thank you all for your replies! > > You all basically suggest the simplest experiments ann of which have > already been done. What I needed is an idea for "something" which requires > couple thousand gates (sponsor's limitation on the simplicity of the demo). >Article: 22373
Philip, Thanks really for all you help and your very explicit post. I just ask you to clean some things in your post... Firstly, when you explain that the Program/ pull down, it's naturally me that must pull down this line ? Next the Init/ line pull up, so drive by the FPGA, yes ? But when I power on the FPGA, must I pull down the Prg/ line ? And when the init/ signal pull up after, must I pull up the prg/ pin ? Secondly, you have very good explain the bitstream format. But we are agree that all bits on the bitstream must be swap, so the length count too. So when we see the bistream file with the length count 42409 for example like: 0000 0000 1010 0101 1010 1001 I must send data in this byte order but swapped of course, so : 0000 0000 1010 0101 1001 0101 yes ? Because I think it's stange for the internal serial latchs to swap after the first and the third byte.... Perhaps it's the lesss significant byte before to the most significant ? (but of course with all bits swapped) > This tells the FPGA that the next 24 bits are the total bitstream > length, and they are sent MSB first. > MSB = Most Significant Bit of Byte ? :) With your explication I have understand why we have just the header on the DOUT pin, very thanks ! You're most explicite than the data book :) For me, now, when I power on the FPGA, init? is high. I pull down after Prg/ and wait that init/ is high (true of course) and send all bits. But there a allways bit reported on the DOUT pin. So my FPGA has never detect the header, no ? > So, when you say you see ALL of the bitstream on DOUT, I know something > is wrong. There are only three ways I know of that this can happen: > > 1) DIN and DOUT are shorted together > I have test my board and no problem :( > 2) The chip has not yet seen the '0010' code and thinks it is still > copying the header > yes perhaps it's this but why I read this sequence on the DOUT pin ? So I think much that the internal logical of the FPGA has not taking this sequence but it is really read... %( Perhaps I must pull up program/ pin before sended all the bitstream bits ? > 3) The chip thinks it is FULL, but the length count has not yet matched > stange because I have check all the bistream to verify fill nibble, crc, start byte, write extended, header, length counter and so on.... and all is GOOD. > I am absolutely sure. Look at the header coming out of DOUT. It should > look like: > > 1 1 1 1 1 1 1 1 1 1 1 1 0 0 1 0 H H H H H H H H > and I have 1 1 1 1 1 1 1 1 1 1 1 1 0 0 1 0 [LENGHT BITS] ... strange !!!!! I think that my FPGA isn't waiting bitstream file when I send them... > Although CCLK is a fairly slow clock, the config logic contains some very > fast logic, and glitches on the CCLK, including crappy edges due to poor > termination, can cause double clocking, etc. > perhaps... I have no tested it... > >> An unloaded HDC could be at 5V, but LDC should be near ground. What do you > >> have connected to it? > >> > > > >Just a volt-tester :( It's really strange to see 1.1V on the LDC/ line ! > > I agree. Check for shorts, a pull up resistor?, dead chip, dead volt-tester? > No shorts, no pull up resistor and the volt-tester is OK. I have detected that LDC is near 1V and Done too ! :( So when I power on the FPGA, I can see: DONE = 1V !!! INIT/ = 5V (ok I think, the memory is clear on the power on step) HDC = 5V LDC/ = 1V !!! Must I trash my FPGA ? :'( Thanks for all your time to help me, Best regards, Sebastien, > > Good luck, > > Philip FreidinArticle: 22374
Hi Sebastien, I wouldn't worry about the configuration before solving the LDC and DONE signal level problem. Are all your ground pins connected? What is the voltage level on these ground pins? What is your reference point when you make these measurements? If you find more than 1V between LDC and an FPGA ground pin something is definitely wrong. Maybe you have a conflict on LDC with another signal that is high. Solve this problem first.Then check CCLK for ringing, double clock edges, etc. You do not have to pulse PRGM on power on but PRGM must be high before starting configuration (INIT is low as long as PRGM is low and you must wait for INIT to go high before attempting the configuration). For configuration do you use a download cable or an on-board processor? If you generate the bitstream yourself with a processor you should not use the *.bit file but create a hex file with promgen. The byte swapping changed at some point (between XACT and M1 I think) but if you swap you swap all bytes so there are only two combinations to try. DOUT should stay high after echoing the first five bytes. INIT going low during the configuration process means an error in the bitstream was detected by the FPGA (there are some frame and/or CRC bits embedded in the bitstream). "Sebastien Favard (Gordh)" wrote: > Philip, > > Thanks really for all you help and your very explicit post. > I just ask you to clean some things in your post... > > Firstly, when you explain that the Program/ pull down, it's naturally me that > must pull down this line ? Next the Init/ line pull up, so drive by the FPGA, yes > ? > But when I power on the FPGA, must I pull down the Prg/ line ? And when the init/ > signal pull up after, must I pull up the prg/ pin ? > > Secondly, you have very good explain the bitstream format. But we are agree that > all bits on the bitstream must be swap, so the length count too. So when we see > the bistream file with the length count 42409 for example like: > > 0000 0000 > 1010 0101 > 1010 1001 > > I must send data in this byte order but swapped of course, so : > 0000 0000 1010 0101 1001 0101 > > yes ? > Because I think it's stange for the internal serial latchs to swap after the > first and the third byte.... Perhaps it's the lesss significant byte before to > the most significant ? (but of course with all bits swapped) > > > This tells the FPGA that the next 24 bits are the total bitstream > > length, and they are sent MSB first. > > > > MSB = Most Significant Bit of Byte ? :) > > With your explication I have understand why we have just the header on the > DOUT pin, very thanks ! You're most explicite than the data book :) > > For me, now, when I power on the FPGA, init? is high. I pull down after Prg/ and > wait that init/ is high (true of course) and send all bits. > But there a allways bit reported on the DOUT pin. So my FPGA has never detect > the header, no ? > > > So, when you say you see ALL of the bitstream on DOUT, I know something > > is wrong. There are only three ways I know of that this can happen: > > > > 1) DIN and DOUT are shorted together > > > > I have test my board and no problem :( > > > 2) The chip has not yet seen the '0010' code and thinks it is still > > copying the header > > > > yes perhaps it's this but why I read this sequence on the DOUT pin ? So I think > much that the internal logical of the FPGA has not taking this sequence but it is > really read... %( > Perhaps I must pull up program/ pin before sended all the bitstream bits ? > > > 3) The chip thinks it is FULL, but the length count has not yet matched > > > > stange because I have check all the bistream to verify fill nibble, crc, start > byte, write extended, header, length counter and so on.... and all is GOOD. > > > I am absolutely sure. Look at the header coming out of DOUT. It should > > look like: > > > > 1 1 1 1 1 1 1 1 1 1 1 1 0 0 1 0 H H H H H H H H > > > > and I have 1 1 1 1 1 1 1 1 1 1 1 1 0 0 1 0 [LENGHT BITS] ... > > strange !!!!! I think that my FPGA isn't waiting bitstream file when I send > them... > > > Although CCLK is a fairly slow clock, the config logic contains some very > > fast logic, and glitches on the CCLK, including crappy edges due to poor > > termination, can cause double clocking, etc. > > > > perhaps... I have no tested it... > > > >> An unloaded HDC could be at 5V, but LDC should be near ground. What do you > > >> have connected to it? > > >> > > > > > >Just a volt-tester :( It's really strange to see 1.1V on the LDC/ line ! > > > > I agree. Check for shorts, a pull up resistor?, dead chip, dead volt-tester? > > No shorts, no pull up resistor and the volt-tester is OK. > > I have detected that LDC is near 1V and Done too ! :( > So when I power on the FPGA, I can see: > > DONE = 1V !!! > INIT/ = 5V (ok I think, the memory is clear on the power on step) > HDC = 5V > LDC/ = 1V !!! > > Must I trash my FPGA ? :'( > > Thanks for all your time to help me, > > Best regards, > > Sebastien, > > > > > Good luck, > > > > Philip Freidin
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z