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
--------------92C391979D5F11BD267F9D04 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Goran, When we added the DFS in the DCM (I know, it is all my fault - I was on the DCM development team doing verification....I can't believe how strange real life is some times) it created CLKFX, which is M/D the frequency of CLKIN, or D/M the period of CLKIN. To constrain a design properly, you need to know these things. Teaching the tools how to deal with this required a lot of work, and getting all of it covered wasn't easy, as you suggest. First time I saw this post I thought, "curious, why does this seem familiar?" When I saw the internal thread on the software solution, it suddenly dawned on me, "oh, yes, we added this to support the DFS and the CLKFX period...." Fix is coming soon. There is a simple workaround: (contact the hotline for details): "If you look in the timing report do you see timing requirements for 0.001ns? If you do then this is due to the Trace tools rounding up and rounding down when dealing with CLKFX outputs. Its a known issue and will get solved in Flint. The way to get round it is to have an exact multiple of the CLKFX output. e.g I had a customer who had the same issue. He had a 24.576MHz clock(40690 ps period) and I was getting the large failures.He had one DCM which gave a CLK2X output. He required a 1.5X output on the CLKFX from one DCM and he also required a 2x output from a CLK2X on another DCM. Thats why the tools were having a problem trying to sort out the timing requirement between the 2 clock domains. The first thing I did was to change the timing constraint to 40500 ps in the UCF file. This meant that the CLKFX output eas now 40500 /3 ps = 13500 ps. When I ran that through the tools it went through OK." Just trying to stay one step ahead, Austin Goran Bilski wrote: > Kevin, > > Glad I could help. > > I'm not sure why it wasn't fixed in 4.2, probably because it was not > an easy fix. > The period has to be non-integer and with a lot of decimal digits. I > think that the problem is due > to rounding errors with floating point calculations. > > I'm told that it will be fixed in our next major release. > > Göran > > Kevin Neilson wrote: > >> Goran,You're right... I thought this didn't work because I changed >> the period in the UCF to an integer and saw no difference but forgot >> that I had a period constraint in the NCF too so I just deleted the >> NCF. Thanks a lot... you save me a lot of time. But since you're >> from Xilinx maybe I can complain a bit... how come I have version >> 4.2 and this problem still persists? Am I the only person that uses >> noninteger periods? -Kevin >> >> "Goran Bilski" <goran@xilinx.com> wrote in message >> news:3C99089E.57DA27B5@xilinx.com...Hi, >> >> I actually run in to this problem a little while ago. >> The reason for the huge timing delays is when you are >> using DLL and has a clock period constraint that >> has many decimals. I think that there are some rounding >> errors in the timing tools. >> So just change your clock period to 41 ns and the problem >> should go away >> >> Göran >> >> >> Kevin Neilson wrote: >> >> > All,I keep running into this problem all the time in >> > which I have a route that misses my constraint by tens of >> > thousands of nanoseconds. I'm using the Xilinx 4.1 PAR >> > tools. In this case the bad paths are ones that cross >> > from a domain with a 20ns period to a domain with a 10ns >> > period. The faster domain is generated from a DLL locked >> > to the first, so while it is twice the freq, it is >> > synchronous to the first. I'm taking care to read data >> > in the second domain only on "even" cycles of the first >> > domain, so the data has 20ns to get from the slow domain >> > to the fast.The first evidence of a problem comes during >> > routing:End of iteration 1 >> > 22869 successful; 0 unrouted; (152088) REAL time: 5 mins >> > 34 secsYou've all cringed at seeing this message before. >> > Then, in the PAR summary, I see >> > this:-------------------------------------------------------------------------------- >> > >> > * PERIOD analysis for net "clk_management/f | 10.416ns >> > | 38591.280ns | 4 >> > irclk_dcm_clk2x" derived from NET "clk_m | >> > | | >> > anagement/CLK_ibufg" PERIOD = 41.667 nS | >> > | | >> > HIGH 50.000000 % | >> > | | >> > >> > -------------------------------------------------------------------------------This >> > is obviously a problem: my constraint for the fast clock >> > domain is 10.4ns, and one path requires 38591ns, meaning >> > I need to slow my clock to the kilohertz range. Here's >> > the detail from >> > Trace:================================================================================Timing >> > constraint: PERIOD analysis for net >> > "clk_management/firclk_dcm_clk2x" derived from NET >> > "clk_management/CLK_ibufg" PERIOD = 41.667 nS HIGH >> > 50.000000 % ; divided by 2.00 and duty cycle corrected to >> > 10.416 nS HIGH 5.208 nS 29336 items analyzed, 58 timing >> > errors detected. Minimum period is >> > 38591.280ns.--------------------------------------------------------------------------------Slack: >> > -3.704ns (requirement - (data path - negative clock >> > skew)) Source: dpll/theta[12] >> > Destination: fir/phase_reclock[5] >> > Requirement: 0.001ns Data Path Delay: >> > 3.705ns (Levels of Logic = 4) Negative Clock Skew: >> > 0.000ns Source Clock: sclk rising at >> > 216975.695ns Destination Clock: firclk rising at >> > 216975.696ns Data Path: dpll/theta[12] to >> > fir/phase_reclock[5] Location Delay >> > type Delay(ns) Physical >> > Resource >> > Logical Resource(s) >> > ------------------------------------------------- >> > ------------------- SLICE_X57Y32.YQ >> > Tcko 0.568 >> > theta[13] >> > dpll/theta[12] SLICE_X54Y33.F1 net >> > (fanout=3) 0.551 theta[12] >> > SLICE_X54Y33.COUT Topcyf 0.769 >> > fir/phase_reclock[2] >> > fir/phase_reclock_qxu[2] >> > fir/phase_reclock_cry[2] >> > fir/phase_reclock_cry[3] SLICE_X54Y34.CIN net >> > (fanout=1) 0.000 fir/phase_reclock_cry[3]/O >> > SLICE_X54Y34.Y Tciny 1.446 >> > fir/phase_reclock[4] >> > fir/phase_reclock_cry[4] >> > fir/phase_reclock_s[5] SLICE_X54Y34.DY net >> > (fanout=1) 0.001 fir/phase_reclock_s[5] >> > SLICE_X54Y34.CLK Tdyck 0.370 >> > fir/phase_reclock[4] >> > fir/phase_reclock[5] >> > ------------------------------------------------- >> > --------------------------- >> > Total 3.705ns >> > (3.153ns logic, 0.552ns >> > route) >> > (85.1% logic, 14.9% >> > route)--------------------------------------------------------------------------------This >> > is just whack. You can see that the path delay is 3.7ns, >> > which easily meets the 20ns period of the slow clock >> > (sclk). However, for some reason it thinks the source >> > clock is sclk rising at 216975ns. Where did that come >> > from? And how did it get a slack of -3.704ns? Also, >> > where did the 38591ns period in the PAR summary come >> > from? That's not even close to 216975. This path really >> > shouldn't be analyzed at all. The Xilinx answer files >> > state that 4.1i doesn't analyze paths that cross clock >> > domains. Sometimes when I see this problem, I can "fool" >> > PAR by putting a FROM-TO in the UCF that explicity states >> > that paths from the "sclk" domain to the "firclk" domain >> > have 20ns. However, this isn't working now, and Trace >> > claims that 0 items are analyzed using that TIMESPEC, >> > even though there are obviously many paths that fit that >> > description.Has anybody else seen this?-Kevin >>Article: 41301
I'm trying to program my Altera MAX7128SLC84-15 in JTAG mode, and I'm getting nowhere fast. This is the first time I've tried this, so I may be doing something obvious wrong... Firstly some information about how I'm doing it. I know this not the best way, but I'm only at university doing a project with a very limited budget (my own budget) and very limited time. The Altera is going into a PLCC to DIL converter, which is in a hand soldered circuit that should let me program the PLD and not a lot else, and it's all done on a matrix board. So there's the first 100 places where I could have made an error :) The power supply is running at 4.5 volts comming directly from a regulated AC/DC adapter which I picked up at my local electronics store. It's at the low end of the recommended supply voltages, but should be ok I think. I'm using a NEF-A-P (http://www.nefdesign.com/) programmer because it's cheaper than the ByteBlasterMV and works at a good range of voltages. I'm assuming this is in good working order... I'm pretty sure I've got everything connected correctly - I've checked many times (following the altera diagrams and the report file for my program) - but when I click on "Detect JTAG Chain Info" in the Altera Stand Alone Programmer it says it can't detect any devices. So.... I know there are loads of places that this could be wrong, but can anyone tell me where the most likely points are? Or have I done something fundementally wrong? Any help at all would be hugely apreciated! Thanks, James.Article: 41302
Thanks, Nicholas, but those with lower than max-length have less than (2^N)-1. Two app notes give values to 168, but not quite up to 257... http://www.xilinx.com/xapp/xapp052.pdf and http://www.xilinx.com/xapp/xapp210.pdf (the latter probably references the former). Nicholas Weaver wrote: > In article <abc3b185.0203242257.1cf8a4ca@posting.google.com>, > anish <anish@myrealbox.com> wrote: > >hi all, > > would be glad to know about effcient implmentation of LFSR of odd > >length i.e not powers of 2 ...like 257 ...is it possible if so how... > >thanks in advance > > All max period shift registers of size N have a length of (2^N) - 1. > > -- > Nicholas C. Weaver nweaver@cs.berkeley.eduArticle: 41303
In comp.arch.fpga rickman <spamgoeshere4@yahoo.com> wrote: > I think that most people don't want to simulate because it is unfamiliar > territory for them. I am in that camp. I would perfer not to, but I am > not willing to take a chance on 100 MHz clock lines which may be run up > to 133 when the faster chip comes out. Yes, I know that the clock speed > is not what is important, but rather it is the edge rate. But to allow > the clock to speed up the edge rate will also go up. > But I am concerned that I will not have the correct data when I perform > the simulation. I still need to close the loop to get valid data that > reflects my PCB. That is an item that I will have to research further. > I am going to start with an old copy of the Motorola ECL data book. It > has a good chapter on Stripline and Microline (if I am remembering the > terms correctly) and calculating all the relevant characteristics... if > I can get the appropriate data on the PCB materials. I worked for a company that subcontracted some of this stuff out when we were getting started. The contractor we used did a nice job - their website is http://www.avid-tech.com. They also sold the tools (hyperlynx) to us after we got up to speed. (No affiliation, etc, etc) -- "The sooner you fall behind, the more time you'll have to catch up!"Article: 41304
Thank you to all who replied! I value your insight into the problem. I'm going to see where I can get a copy of Knuth's book to see for myself... Thanks again, EricArticle: 41305
James Thurley wrote: > > I'm trying to program my Altera MAX7128SLC84-15 in JTAG mode, and I'm > getting nowhere fast. This is the first time I've tried this, so I may be > doing something obvious wrong... > I know this not the best > way, but I'm only at university doing a project with a very limited budget > (my own budget) and very limited time. Altera will show you how to make your own byteblaster. see page 4 of http://www.altera.com/literature/ds/dsbytemv.pdf -- Mike TreselerArticle: 41306
I don't see why you couldn't use just a subset of a maximal length LFSR... you could just reset the LFSR reg when it hits a certain value. For example, if you have a 9-bit LFSR that you reset to 9'b1, you and you know that the 257th value in that sequence is x(257), then you can just reset the LFSR back to 9'b1 whenver you hit x(257). To maintain full speed you can instead detect x(256) or x(255) instead and pipeline the detector circuitry so you only have one level of LUT logic. "anish" <anish@myrealbox.com> wrote in message news:abc3b185.0203242257.1cf8a4ca@posting.google.com... > hi all, > would be glad to know about effcient implmentation of LFSR of odd > length i.e not powers of 2 ...like 257 ...is it possible if so how... > thanks in advance > anishArticle: 41307
Kevin, An old tried and true technique that I used in XC3000 fpga's. Find the nth count value, detect it, and synchrounously load the first value again. Austin Kevin Neilson wrote: > I don't see why you couldn't use just a subset of a maximal length LFSR... > you could just reset the LFSR reg when it hits a certain value. For > example, if you have a 9-bit LFSR that you reset to 9'b1, you and you know > that the 257th value in that sequence is x(257), then you can just reset the > LFSR back to 9'b1 whenver you hit x(257). To maintain full speed you can > instead detect x(256) or x(255) instead and pipeline the detector circuitry > so you only have one level of LUT logic. > > "anish" <anish@myrealbox.com> wrote in message > news:abc3b185.0203242257.1cf8a4ca@posting.google.com... > > hi all, > > would be glad to know about effcient implmentation of LFSR of odd > > length i.e not powers of 2 ...like 257 ...is it possible if so how... > > thanks in advance > > anishArticle: 41308
See "On Arbitrary Cycle n-Bit LFSRs", http://www.fpgacpu.org/usenet/lfsrs.html, and the lfsr design program in the XSOC kit at http://www.fpgacpu.org/xsoc/. Jan Gray, Gray Research LLCArticle: 41309
It wouldn't bother me so much that this is a known issue if Xilinx made the workaround easy to find. Even if there is an answer in the help files, it is useless if one can't find it. I spent an hour typing in every possible search pattern that might relate to this problem and never did I find answer #12174. At least not in the first several dozen hits. "Jason Daughenbaugh" <fpgaguy@aedinc.net> wrote in message news:3efced06.0203250838.795ada9e@posting.google.com... > > But since you're from Xilinx maybe I can complain a bit... how come I > > have version 4.2 and this problem still persists? Am I the only person > > that uses noninteger periods? > > No, you are not the only one. > > I have seen this problem many times since I upgraded to 4.1i. > > Xilinx support pointed me to answer #12174. > > It is for Virtex2 DCM's, but he said that the problem also exists for > Vitex/spartan-2 DLL's. > > A agree that it is a little dissappointing that has not been fixed in > any service pack or 4.2i, especially since it has apparently bitten > several engineers and they have known about it for a while (I > contacted them in December / January, and he told me that it is a > "known issue.") Hopefully it will be fixed in the next service pack? > But answer 12174 does not seem to indicate any plan to fix it. > > It is almost comical to see the report say that something with two > logic levels can only run at 33kHz in a Spartan-2 FPGA. Seems like > something Xilinx would like to avoid... > > Jason Daughenbaugh > http://www.aedinc.netArticle: 41310
My site has a vhdl lfsr + reference to book that has all the equations for various sizes. ---------------------------------------------------------------------------- Ben Cohen Publisher, Trainer, Consultant (310) 721-4830 http://www.vhdlcohen.com/ vhdlcohen@aol.com Author of following textbooks: * Real Chip Design and Verification Using Verilog and VHDL, 2002 isbn 0-9705394-2-8 * Component Design by Example ", 2001 isbn 0-9705394-0-1 * VHDL Coding Styles and Methodologies, 2nd Edition, 1999 isbn 0-7923-8474-1 * VHDL Answers to Frequently Asked Questions, 2nd Edition, isbn 0-7923-8115 ------------------------------------------------------------------------------Article: 41311
David Frith wrote: > > Hello all > > I've just loaded on ISE 4.2i and the first design I ran through gives me an > error at ngdbuild. This is with exactly the same input files as 4.1i which Did you instal the SP1 already ? Probably it goes away ...Article: 41312
Maybe you have a dead device. My students have destroyed EPM7064S-devices several times having no ground connection between the programming computer and PSU supplying the circuit board. If you have bad luck, ground pin is not the first pin to makimg connection when inserting programming cable, but a signal pin routed to Altera device. Surge voltage and current caused by different potential of computer and the circuit board can easily kill this pin. So always make a connection between the case of computer and the ground of the pcb before connecting the programming device. And firstly remove the programming device and then the external ground connection. It's also a good idea to have shottky diodes from every signal-pins of JTAG to ground and VCC. Dual shottky BAT54S will handle glound and VCC simultaneously -- Tuomo AuerArticle: 41313
Hi all,
According to the Spartan II datasheets, a pin I must use is defined as "I,
GCK1" for its function. Because of the prototyping board I am using - and
what I am trying to do!, I must use this pin as an input. Here is a portion
of my VHDL code:
--Stuff here
signal WrEnable: std_logic;
-- in arch begin/end
-- Invert the input pin P_WR_L to get active high signal
WrEnable <= not P_WR_L;
-- Instantiate RAM block from Coregen
ram_block : rammodule
port map (
addr => P_Address, -- Address pins
clk => SCLK, -- System clock
din => P_Data, -- Data pins
dout => RData, -- To tri-state buffers
we => WrEnable); -- Write Enable signal
This synthesises fine. However, when I attempt to implement this design, I
get the following error:
Running directed packing...
ERROR:Pack:1107 - Unable to combine the following symbols into a single IOB
component:
PAD symbol "p_wr_l" (Pad Signal = p_wr_l)
BUF symbol "p_wr_l_IBUF" (Output Signal = p_wr_l_IBUF)
Each of the following constraints specifies an illegal physical site for
a
component of type IOB:
Symbol "p_wr_l" (LOC=P77)
Please correct the constraints accordingly.
Problem encountered during the packing phase.
The associated constraints file has the following entry:
NET "p_wr_l" LOC = "P77";
I do not understand the error, nor how to fix it! BTW, if I use a I/O only
pin, instead of P77, everything works fine! But of course, I cannot do
that! *sigh*
Thanks for your help!
-Bob
Article: 41314John_H wrote: > Thanks, Nicholas, but those with lower than max-length have less than (2^N)-1. > > Two app notes give values to 168, but not quite up to 257... > http://www.xilinx.com/xapp/xapp052.pdf > and > http://www.xilinx.com/xapp/xapp210.pdf > Not really. Thetwo app notes just give the circuitry for different values of n. The question, the way I understood it, was how to design an LFSR that is repetitive for different numbers, not just (2 exp n) -1. Conceptually, the trick would be to change the input polarity at a certain point, for only one clock tick, and thus skip the appropriate number of clock ticks. Easily said, and guaranteed to work, but I am not good enough at math to implement it. :-) 257 requires a 9-bit LFSR. So you can try out "my" method by brute force. That's what computers are good at... Peter AlfkeArticle: 41315
Falk, Thanks for your reply. I am using short (less than 3") wires for the power and ground. I've got decoupling caps on both the SRAM and 8051. I'm using a 7805 5V regulator to supply the 5V to the SRAM/8051. I've got decoupling caps on the input (22uf) and the output (10uf and .1uf) of the 7805. I've run 4 wires from the ground of the 7805 to 4 of the decoupling capacitors on the CPLD to help my grounding issues. These are in addition to several other wires I have creating a common ground between the 5V and 3.3 volt logic. I'm using the thickest wire I can that will fit through the PCB holes. I'm not sure what else I can do to fix my grounding issues. There's not many more places I can solder a wire to. Thanks for your help. Mike "Falk Brunner" <Falk.Brunner@gmx.de> wrote in message news:<a7l39c$m7io0$1@ID-84877.news.dfncis.de>... > "Mik e Payne" <halstoninaustin@yahoo.com> schrieb im Newsbeitrag > news:b1946105.0203232118.7d4ecbeb@posting.google.com... > > > the low address lines and control read/write enable). I'm using an > > AVNET evaluation board for the prototyping. I cannot get this design > > How do you connect the 8051 and SRAM to the demo board? Via 10 feet of > ribbon cable with just 1 ground wire ? ;-) > Just kidding. > Serious, I think a 8051 isnt such a killer (IOs are not too fast) to produce > heavy ground bounce and/or ringing if the setup is reasonably OK. Use short > (<10 cm) connection cables, good ground connections (close to the signals, > not fly-around ground wire) and everything should be OK. > > > I'm thinking that I'm not understanding something about this CPLD. It > > has a 32.768KHz clock going into CLK0 and CLK1-3 are tied to ground. > > Do I need to have clocks on all of these lines? Does the clock need > > No. As far as I acn see you are just running the asynchronous interface > between the 8051 and SRAM through the CPLD, so there is no need for a clock.Article: 41316
Mik e Payne wrote: > Falk, > > Thanks for your reply. I am using short (less than 3") wires for the > power and ground. I've got decoupling caps on both the SRAM and 8051. > I'm using a 7805 5V regulator to supply the 5V to the SRAM/8051. I've > got decoupling caps on the input (22uf) and the output (10uf and .1uf) > of the 7805. I've run 4 wires from the ground of the 7805 to 4 of the > decoupling capacitors on the CPLD to help my grounding issues. These > are in addition to several other wires I have creating a common ground > between the 5V and 3.3 volt logic. I'm using the thickest wire I can > that will fit through the PCB holes. I'm not sure what else I can do > to fix my grounding issues. There's not many more places I can solder > a wire to. I'm not exactly clear on what the CPLD is mounted on. Is it on the Avnet evaluation board? If so, then the power supply bypassing is all by etched traces already on the board? If all that is so, then bypassing of the CPLD should be adequate. I'e done a number of XC9572 designs and not had any surprises with power decoupling, the chips are quite well behaved. I would expect the CoolRunner should be the same. But, there is the 5/3.3V interface that could be messing things up. Could the 3.3 V outputs from the CoolRunner be causing the 8051 or SRAM to go haywire? You mentioned a 32 KHz clock, but the VHDL looks pretty combinatorial, not clocked. So, where does CLK0 go, and what does it do? If you are not using the clock in your equations, then don't provide it to an input of the chip. No telling what it has configured that pin for if it is not specified in the equations. JonArticle: 41317
rickman wrote: > Yes, I just finished looking at that. There is quite a discrepance > between the pricing that Xilinx lists on their web page for HUGELY high > volumes and the prices we little people get. I saw $5.50 for an XCS30XL > on the Xilinx promo page and >$30 at Avnet for 100. Should be cheaper than that, at least in TQ144 package. I paid $30 (ea) for 5 XCS30-3TQ144 parts, and the NON-XL cost a lot more than the XL. There IS a big difference in price based on the package, though. JonArticle: 41318
You can also use a logic probe or oscilloscope to verify that data is flowing to the chip's TDI pin - and *should* be coming from its TDO pin. If the first isn't true, the interface isn't driving the pin or it's shorted. If TDI works and TDO doesn't, the chip is probably gone, though again a short could be the culprit. TCK should pulse when you use the interface too. Best to you and your project! JimArticle: 41319
Christopher.Saunter@durham.ac.uk (Christopher Saunter) writes: >Eric Crabill (eric.crabill@xilinx.com) wrote: >: I am looking to build a circuit for sorting small data sets, >: and am hoping someone here might have some pointers for where >: I should start looking for algorithms to do it. (snip) >I got thinking about sorting, and this is what I came up with. >It should sort data at high speed, and accepts all words in >a single cycle in parallel, and spits them out in parallel, >sorted, a fixed number of cycles later. I think with a bit >of effort in layout it would run very fast as well. However, >it makes rather less efficient use of a Xilinx device than >the FIFO solution, as it uses flip-flops for data storage, not >LUTs. >Please lay into any problems it has, I'm out to learn! >--- >The design consists of a number of pipeline stages, each of which >partially sorts the data by sorting pairs of values. >We have N words. Conceptually these are split into N/2 pairs >of words, each of which are sorted based on the 4 bit key. >This could be done with a 4 bit magnitude comparitor and two 2:1 >mux's - see my noddy diagram at >http://www.dur.ac.uk/christopher.saunter/sort1.bmp >So the first stage of the sorting pipeline is as follows: (snip) Fast sorting algorithms are O(n log n) comparisons. Here you are doing m comparisons at a time, maybe even n comparisons. I don't know if there is an O(n log n) parallel sort algorithm. I did once implement a maximum of two 16 bit numbers in XC4000 series. It is convenient in that the carry logic does the compare and the LUT's do the select, so it can be done in 9 CLBs. It seems that newer Xilinx FPGA's don't allow this separate carry logic operation. I would look into systolic array algorithms, as they tend to be good for doing this. According to my systolic algorithms book bubble sort is about the most efficient systolic sort algorithm, which is pretty much what you were describing. You need n cells and n cycles to sort n elements. -- glenArticle: 41320
Getting the correct length by selectively inverting the input works, but it can be
challenging to find the right timing and decode. Back in the 3000 days, I found it
was easier to decode a specific state and then reset the shift register. You could
easily backup the count or advance the reset state to get an easy decode followed by
one or a few registers to adjust the timing. I even went as far as writing an LFSR
tool that would give you the minimum decode for the state n counts away from the
current state, or with a decode pattern and current state tell you how many counts
till the decode hit.
Peter Alfke wrote:
> John_H wrote:
>
> > Thanks, Nicholas, but those with lower than max-length have less than (2^N)-1.
> >
> > Two app notes give values to 168, but not quite up to 257...
> > http://www.xilinx.com/xapp/xapp052.pdf
> > and
> > http://www.xilinx.com/xapp/xapp210.pdf
> >
>
> Not really.
> Thetwo app notes just give the circuitry for different values of n.
> The question, the way I understood it, was how to design an LFSR that is
> repetitive for different numbers, not just (2 exp n) -1.
> Conceptually, the trick would be to change the input polarity at a certain point,
> for only one clock tick, and thus skip the appropriate number of clock ticks.
> Easily said, and guaranteed to work, but I am not good enough at math to
> implement it.
> :-)
> 257 requires a 9-bit LFSR. So you can try out "my" method by brute force. That's
> what computers are good at...
>
> Peter Alfke
--
--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
Article: 41321From what I know decoded bluetooth data comes out with 1us period. Maybe there are noise like spikes and phase shift. Is there any reference design on how to recover this data stream and create a clock? thanks.Article: 41322
"Ray Andraka" <ray@andraka.com> wrote in message news:3C9FBD85.3022F77@andraka.com... > Getting the correct length by selectively inverting the input works, but it can be > challenging to find the right timing and decode. That's what my aftorementioned little LFSR design program does... And as long as I am replying to this thread a second time, I would like to remind folks that in an FPGA architecture with SRL16 (16-bit programmable output tap shift registers in a single 4-LUT), you can often design simpler divide-by-n counters using a couple of SRL16s. I recommend Ken Chapman's 'techXclusives' articles on SRL16E: http://www.xilinx.com/support/techxclusives/SRL16-techxclusive2.htm http://www.xilinx.com/support/techxclusives/SRL16-techxclusive3.htm http://www.xilinx.com/support/techxclusives/SRL16-techxclusive4.htm The clock division discussion is in part 2. And you can even mix paradigms, using an LFSR made with an SRL16-based shift register, as Maria George and Peter Alfke discuss here: http://www.xilinx.com/xapp/xapp210.pdf. Jan Gray, Gray Research LLCArticle: 41323
"Tuomo Auer" <tuomo.auer@removethis.hut.fi> skrev i meddelandet news:a7o3eq$g6n$1@tron.sci.fi... > Maybe you have a dead device. My students have destroyed EPM7064S-devices > several times having no ground connection between the programming computer > and PSU supplying the circuit board. If you have bad luck, ground pin is not > the first pin to makimg connection when inserting programming cable, but a > signal pin routed to Altera device. Surge voltage and current caused by > different potential of computer and the circuit board can easily kill this > pin. So always make a connection between the case of computer and the ground > of the pcb before connecting the programming device. And firstly remove the > programming device and then the external ground connection. It's also a good > idea to have shottky diodes from every signal-pins of JTAG to ground and > VCC. Dual shottky BAT54S will handle glound and VCC simultaneously > -- > Tuomo Auer > These devices seem kind of sensitive. I recently built myself a ByteBlasterMV cable and a small pcb for an EPM7064S with headers for all pins and JTAG. The first time I tried it everything seemed to work ok, I could examine the chip and readout the data(though I thought the chips would be blank when purchased but it was not). Then I wired everything up to test the program I wrote and it didnt work anymore. I could not find anything wrong with the way it was hooked certainly not anything that would kill the chip. So it might have been fried the way Tuomo suggested or by ESD. If it was the way Tuomo suggested I think its weird that this is not stated in the ByteBlaster manual or any of the application notes regarding ISP. I checked the TCK and TDI signals with a scope and they seemed ok but the TDO signal was stuck at 0 V. ArbitraryArticle: 41324
Jan,
I agree, the SRL16 is a wonder drug. I don't however like to use it as a closed
loop state machine as described by Ken because such a design will not self
recover in the event of an upset. The SRL16 only gets initialized on
configuration, so if for some reason you get an upset (and in the .15 micron it
does sometimes happen), your state machine carries that upset state bit until
the device is reconfigured. In my book, that is poor design practice. As soon
as you add the logic to detect the illegal states, the size gets considerably
larger (it may be more advantageous to use TMR here).
The LFSR in an SRL16 is a different story, since in that case there is only one
illegal state, not 2^n-n. The SRL16s are really nice for compact LFSRs as long
as you don't need to reset them in less than N clocks and you don't need access
to more than a few bits. That makes the SRL16 LFSR fine for random pattern
generation, but not so hot for state machines. These days, I am not using LFSRs
very often at all.
Jan Gray wrote:
> "Ray Andraka" <ray@andraka.com> wrote in message
> news:3C9FBD85.3022F77@andraka.com...
> > Getting the correct length by selectively inverting the input works, but
> it can be
> > challenging to find the right timing and decode.
>
> That's what my aftorementioned little LFSR design program does...
>
> And as long as I am replying to this thread a second time, I would like to
> remind folks that in an FPGA architecture with SRL16 (16-bit programmable
> output tap shift registers in a single 4-LUT), you can often design simpler
> divide-by-n counters using a couple of SRL16s. I recommend Ken Chapman's
> 'techXclusives' articles on SRL16E:
>
> http://www.xilinx.com/support/techxclusives/SRL16-techxclusive2.htm
> http://www.xilinx.com/support/techxclusives/SRL16-techxclusive3.htm
> http://www.xilinx.com/support/techxclusives/SRL16-techxclusive4.htm
>
> The clock division discussion is in part 2.
>
> And you can even mix paradigms, using an LFSR made with an SRL16-based shift
> register, as Maria George and Peter Alfke discuss here:
> http://www.xilinx.com/xapp/xapp210.pdf.
>
> Jan Gray, Gray Research LLC
--
--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
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