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
"KJ" <Kevin.Jennings@Unisys.com> wrote in message
news:1162320665.907686.101530@h48g2000cwc.googlegroups.com...
>
> Ben Jones wrote:
>
>> There are many problems
>> with wizards and core generators for things like RAMs and arithmetic
>> elements - mostly, they are the wrong level of abstraction for most
>> designs.
>
> Maybe. I find there lack of a standard on the 'internal' side to be
> the bigger issue.
For the smaller "building block" components, I'd say that's not much of an
issue at all. After all, how many different interfaces can you think of for
an accumulator or shift register? Most of the differences between vendors
seem to be superficial (e.g. naming) at that level. The problem I have with
these low-level blocks is that they go against the basic principle of
abstraction; instead of hiding complex functions behind simple interfaces,
they do the exact opposite. And they hold back designers by perpetuating the
"TTL 7400" design mentality.
>> they help designers get the most out of the silicon in those cases where
>> synthesis tools are not sophisticated enough to produce optimal results.
>
> I don't believe that a unique entity
> is required in order to produce the optimal silicon. Once the
> synthesis hits a standardized entity name it would know to stop and
> pick up the targetted device's implementation.
I think that would be great. Of course, vendors' in-house synthesis tools
are unlikely to support that kind of system except for portability between
their own device families.
> Tell me what prevents everyone from standardizing on an interface to
> their components in a manner similar to what LPM attempts to do? The
> chip guys do it for their parts, the FPGA vendors don't seem to want to
> do anything similar on the IP core side.
I don't think anything prevents it, other than whatever all-pervading force
there is in the universe which prevents people from agreeing about things.
:-)
The OpenFPGA initiative have a working group on core interfacing. There's
LPM (obsolete IMHO). There's OCP. There's no shortage of people proposing
ideas for standard interfaces, but there is a shortage of time, money and
energy to do anything about it. I think you'll find most engineers in favour
of standardization to some extent, but there's no one single driving force
for adoption. Some people also see it as a barrier to innovation. (It isn't,
but still, some people see it that way.)
> Can you list any 'standard' function IP where the code can be portable
> and in fact is portable across FPGA vendors without touching the code?
No. But I'm willing to bet that any engineer worth their salt would be able
to write the appropriate glue logic to convert one to the other without
working up a sweat.
In some cases, for example if a customer is using a processor-based system
design environment such as Platform Studio (X) or SOPC builder (A), the
"proprietary" interface to (say) a DDR SDRAM controller is hidden away, to a
great extent, because the tools provide a system-level abstraction.
One thing that greater standardization would do is make it much easier for
third-party IP core developers to create and sell vendor-agnostic IP. If
that really is a viable business model nowadays...
Here's another thought - in many industries (e.g. consumer electronics and
eletricals) the quality of the interface is a big differentiating factor for
the purchaser. Why shouldn't this be true for digital interfacing standards
too? A customer might have a preference for a CoreConnect-based system over
an AMBA-based system, or vice versa, based on which of the interface's
features are relevant to their needs.
BTW I'm not sure how much of this I really fervently believe in, just trying
to illuminate the issue a bit.
>> I'm not denying that there is a risk of vendor lock-in, but I'd dispute
>> that
>> it's the motivating factor for vendors to develop IP.
>
> I was only suggesting that it was an incentive...which you seem to
> agree with.
I would only say it's a question inertia, rather than malice. On a related
note, what do engineers hate more - risk of vendor lock-in, or breaking of
backwards compatibility?
It's certainly an interesting issue!
-Ben-
Article: 111301Bob Perlman wrote: > > on Halloween night, not a single person dressed as metastability > showed up at my door for candy > We had four houses' worth of candy-filled bowls lined up on one long table, which caused many of the evening's spectres to exhibit distinct signs of metastability during the confectionary selection process. Unlike FPGA's, the resolution time seemed inversely proportional to the calendar age of the synchronizer :) Also, I don't recall anyone mentioning it, but Bob's handy dandy guide to planetary landing FSM's seems quite topical of late: http://www.cambriandesign.com/2006/02/synchronizing-fsm-inputs.html BrianArticle: 111302
Jon Elson <elson@pico-systems.com> wrote: > Spartan XL is not the 5 V Spartan, it is 3.3 V, and not pin compatible > with 5 V Spartan. These chips will not work without major changes to > the board. I am doing that, but going to XCS2E. It is a complete > from-scratch redesign. Consider using XC3S...E. Why stick with XCS2E? -- Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------Article: 111303
aravind wrote: > Jeff Cunningham wrote: > > rickman wrote: > > > aravind wrote: > > > > > >>Hi > > >> Im planning to design an SPDIF receiver for implementation on > > >>Spartan 3 FPGA , But im not sure how to go about the design,Does any > > >>one have ideas ? > > >>Thank u > > > > > > > > > I did a quick Google search and found some very informative entries at > > > Wikipedia. To get the low level format description I had to click > > > through to the AES/EBU description and even more detail is available at > > > one of the references given. > > > > > > This should not be a difficult design to figure out, but there are > > > details that require attention depending on your application. > > > > One big detail is are you just receiving the data, or are you also > > recovering a clock to feed to downstream codecs? > > I want to receive the data from spdif and convert it to I2S format to > shift out the audio data to a dac such as cs4334.How do i sample the > spdif signal ,synchronize it and convert the biphase mark code to > normal 16 bit audio data in a register. > I've done all the basic stuff in vhdl like multiplexed 7 segment > display drivers,simple programs on picoblaze processor,etc. The data stream is BMC which is very easy to decode. You just need to consult some references and it should be very obvious. You need to sync your data recovery to the transitions between the bit cells. Get the value of the input following the rising or falling edge. Wait 3/4 bit time and sample the input again. If they match, you have a zero bit, if they are different you have a 1 bit. Then wait for the next edge on the input. You will be bit cell synchronized after sampling a zero bit. The SPDIF data stream is simply the data with some framing around it. If you read a few references the structure is also very simple and easy to parse. A simple counter with a synchronization circuit should suffice. It may not be obvious, but you need to use the data stream clock to generate the clock for your DAC. If you don't, you will either drop data or have to live with a lot of jitter in the sample clock which causes much audio distortion. The digital aspects of this design are very straightforward, the analog aspects are not.Article: 111304
Frank van Eijkelenburg wrote:
> Hi,
>
> I have a bootloader running from internal ram (m4k blocks). I also build
> a standalone application to run from external ram. The application is a
> .bin file which is sent to the bootloader through a serial interface
> (RS232). The bootloader copies the application to external ram and
> executes it. My application is built to run from address 0x00200000. If
> I make a .bin file from the generated .elf file I get a file of about 2
> MB. This is because the alt_exception and alt_irq_handler is laid at
> address 0x20 and 0xEC. AFAIK this is not necessary. Do I have to make a
> linker file to fix this? Or should I use another startup assembly file?
> In case of a linker file, does anyone have an example for this situation?
>
> So the bootloader runs from internal ram (with base address 0) and the
> application runs from external ram (with base address 0x00200000).
>
> TIA,
> Frank
I have to use a custom linker script and I found an easy way to make it (at the
nios forum):
- take the file generated.x in the system library directory;
- copy the file to a location which is not deleted with a "clean project" action;
- search for the sections .entry and .exceptions and map them to external ram;
.entry :
{
KEEP (*(.entry))
} > sram
.exceptions :
{
. = ALIGN(0x20);
*(.irq)
KEEP (*(.exceptions));
} > sram
- in the system library properties tell the IDE you want to use a custom linker
script.
Article: 111305Using Virtex4FX12, laptop P4M 1.7GHz and ISE 8.1 SP3 and EDK 8.2 SP1. Strange, because I rebuld one MB project in 8.2 for S3ESK and it worked fine. I think this are some bugs that emerge from time to time. Lets pray that EDK SP2 will solve the problem. Cheers, Guru Zara wrote: > On 29 Oct 2006 09:43:10 -0800, "Guru" <ales.gorkic@email.si> wrote: > > >I am having about the same experience. > >I upgraded my computer to EDK/ISE 8.2 > > > >1. I upgraded my GSRD2 (PPC, MPMC2, TEMAC) design to v8.2. There were > >actually no problems detected until I used the flashwriter.tcl script. > >I does not work at all. OK, minor thing to remedy. > > > >2. I upgraded my PPC CoreConnect project to 8.2. First the XMD connect > >failure (wrong processor version 0x00000000). Then I connected > >secesfully using "connect ppc hw", but the design does not work at all > >- probably some hw error. The sw crashes when setting interrupt > >controller (working nice in 8.1). > > > >Fu.. that 8.2 and hope for the SP2 to remedy the problems. > > > >Cheers, > > > >Guru > > I am jus wondering if ther problem lies: > 1. Either in the target selected (some problem with Syn/Xlat/Map/Par): > I am using an Spartan 3: 3S400 > 2. Or in the Computer: I am using an AthlonX2, both in the dual > 8.1/8.2 installation, and in a clean 8.2 installation on a bran new > laptop, that also fails. > > Antti? Guru? Do you see any recurrence here? > > ZaraArticle: 111306
Ian wrote: > On 2006-10-31, aravind <aramosfet@gmail.com> wrote: > > Im planning to design an SPDIF receiver for implementation on > > Spartan 3 FPGA , But im not sure how to go about the design,Does any > > one have ideas ? > > How *not* to do it: > > http://projects.jusme.com/project/spdifdac > > (That's my design so I can say that :) > > HTH, > -- > Ian > > "Tamahome!!!" - "Miaka!!!" does your design support only 44.1khz ?if yes what modifications have to be done to support 48khzArticle: 111307
Thanks for all the feedback! I'm going to chew on this for a few hours! But just to clarify, the source of the noise is primarily, but not soley, from the system itself. It's a bead in a viscous fluid. It is being driven by brownian motion, which has a power spectrum (amplitude versus frequency) that goes as 1/f^2. The bead is a sphere, and it has viscous drag, so the power spectrum is flat until 10kHz and then it rolls off. Following the bead at all frequencies is not yet practical. But we certainly don't want to alias the 2 kHz motions down to our 200 Hz control loop. The flat region of the power spectrum is 0.1mV per root hertz, so the whole idea is to filter down to the time response of the the instrument (200 Hz) and at the same time get improved resolution. I.e. at 10 kHz, the signal peak-to-peak fluctuations should be 10 mV, but at 200 Hz, it should be 1.4 mV (providing I don't alias anything!) So I think in this case, decimation doesn't help? These questions about bandwidth and noise- are there any good books that address this. I've actually been picking it up as I go, as I am a scientist and not an engineer, so just the first step of quantifying the resolution of our instrument in nm per root hertz (taking the lead from electrical engineers) was a big step forward in my understanding. For example, another quesiton I've had in my mind is how to deal with an attenuated signal, ie, what if I sampled at 50 kHz where the signal is rolling off due to viscous drag, and tried to compare it to the rest of my signal. I'm sure this is a really basic concept in electrical engineering, so maybe someone knows of a book that speaks about bandwidth and noise and even the fundamental concept of listing noise in nm per root hertz, and how that works, ie does the distribution of noise have to be normal or gaussian, does it have to be flat, etc. Or maybe there isn't such a book and you could write one? Will On Oct 31, 10:37 pm, Ray Andraka <r...@andraka.com> wrote: > will.pa...@gmail.com wrote: > > I think you are right that sampling and then filtering does not buy you > > more S/N ratio. Depends on the source of the noise. It isn't going to help if you have > wideband noise in the signal. However, if the noise is due to > quantization in the ADC, then by decimating you gain effective ADC bits. > This is sort of like averaging the error on many samples to get a > better estimate of one sample assuming the input hasn't changed > significantly over the many samples. You can also shape the noise > induced within the system by employing feedback to push the system noise > into the stopband of your filter. This is the principle behind > delta-sigma converters. > > The classic advantage to oversampling, as I mentioned before is that it > relaxes the specification for your anti-alias filters, making them much > cheaper to implement.Article: 111308
>>>>Hi >>>> Im planning to design an SPDIF receiver for implementation on >>>>Spartan 3 FPGA , But im not sure how to go about the design,Does any >>>>one have ideas ? >>>>Thank u >>> >>> >>>I did a quick Google search and found some very informative entries at >>>Wikipedia. To get the low level format description I had to click >>>through to the AES/EBU description and even more detail is available at >>>one of the references given. >>> >>>This should not be a difficult design to figure out, but there are >>>details that require attention depending on your application. >> >>One big detail is are you just receiving the data, or are you also >>recovering a clock to feed to downstream codecs? > > > I want to receive the data from spdif and convert it to I2S format to > shift out the audio data to a dac such as cs4334.How do i sample the > spdif signal ,synchronize it and convert the biphase mark code to > normal 16 bit audio data in a register. > I've done all the basic stuff in vhdl like multiplexed 7 segment > display drivers,simple programs on picoblaze processor,etc. The downstream DAC will need something like a 128 or 256 FS clock. You will need some sort of state machine to recognize when a flag character is being received. Then you can enable some combinatorial logic such that the trailing edge of the flag generates a FS reference edge for an external PLL such as a 74HC4046. Then use the PLL to multiply the frequency to generate the (typically) 256FS DAC clock reference. You can then use the 256FS signal to clock your SPDIF receiver logic. Because the clock is locked to the data stream, you already implicitly know where the beginning middle and end of the bit cells are, so demodulating the FM data is just recognizing if there was a transition in the middle of the bit cell. You can then shift the data into a shift register, etc., all under control of the state machine. Alternatively, if you have a local clock several times greater than the SPDIF bit rate, you can make a fancier state machine that recognizes edges, counts states to figure out where the bit cell boundaries would be and so on. This all digital approach removes the need for an external analog PLL, but can't provide a low jitter clock reference for your DAC. You might also consider using an external SPDIF receiver from Cirrus or AKM or others, though that may take the fun out of it.Article: 111309
Generalising the question of this discussion I would like to know what does the group here think that code generators are worth? Say Someone comes out with a code generator which requires some input data say, D_in and generates a bunch of output code say, C_out. Given that C_out is something that you already write for your design wether the code generator exists or not, when will the code generator look like a fesible option? Given the following man days(Including coding, verfying and debugging time) for writing D_in and generating C_out VS manual writing of C_out, what is the price you will be willing to pay for the code generator in each case? --------------------------------------------- Development time in Mandays --------------------------------------------- D_in : Manual C_out --------------------------------------------- 1 : 10 1 : 100 1 : 1000 If such a code generator appears on the market will your management wait until a bigname EDA comes out with a me too product or will they buy it from a noname developer? Regards Thomas Andy wrote: > Evan Lavelle wrote: > > Ok, is it worth any more than $0 now? :) > > In a word, no. > > Why go to the trouble of learning a new language to try to do things > like macros, loops, random stimulus, etc. when you have the power of > the VHDL language at your disposal in a VHDL testbench? Now, if you > have vectors from an external model/simulation, those can be applied > with text-io relatively easily from within a vhdl testbench that will > run on any vhdl simulator. > > My "unit level tests" are usually at a high enough level that I need a > lot more capability than is available in any vector based scripting > language. > > AndyArticle: 111310
will.parks@gmail.com wrote: (top posting fixed) > On Oct 31, 10:37 pm, Ray Andraka <r...@andraka.com> wrote: > >>will.pa...@gmail.com wrote: >> >>>I think you are right that sampling and then filtering does not buy you >>>more S/N ratio. > > >> Depends on the source of the noise. It isn't going to help if you have >>wideband noise in the signal. However, if the noise is due to >>quantization in the ADC, then by decimating you gain effective ADC bits. >> This is sort of like averaging the error on many samples to get a >>better estimate of one sample assuming the input hasn't changed >>significantly over the many samples. You can also shape the noise >>induced within the system by employing feedback to push the system noise >>into the stopband of your filter. This is the principle behind >>delta-sigma converters. >> >>The classic advantage to oversampling, as I mentioned before is that it >>relaxes the specification for your anti-alias filters, making them much >>cheaper to implement. > > Thanks for all the feedback! I'm going to chew on this for a few hours! > > But just to clarify, the source of the noise is primarily, but not > soley, from the system itself. It's a bead in a viscous fluid. It is > being driven by brownian motion, which has a power spectrum (amplitude > versus frequency) that goes as 1/f^2. The bead is a sphere, and it has > viscous drag, so the power spectrum is flat until 10kHz and then it > rolls off. Then the advantage to sampling fast and filtering is that you insure that your ADC noise _isn't_ part of your system noise. If you cut out noise at all you'll be cutting out noise that you can't do anything with, anyway. > > Following the bead at all frequencies is not yet practical. But we > certainly don't want to alias the 2 kHz motions down to our 200 Hz > control loop. The flat region of the power spectrum is 0.1mV per root > hertz, so the whole idea is to filter down to the time response of the > the instrument (200 Hz) and at the same time get improved resolution. > I.e. at 10 kHz, the signal peak-to-peak fluctuations should be 10 mV, > but at 200 Hz, it should be 1.4 mV (providing I don't alias anything!) > So I think in this case, decimation doesn't help? I'm not clear on where your control loop is, but if your instrument is inherently low-pass you should be able to control it with the full bandwidth signal, noise and all, and let it follow as best as it can. Assuming that this doesn't overload your actuators, and that you aren't limited to a 200Hz sampling rate, you'll get pretty close to an optimal control. If it _does_ saturate or overload your actuators, of course, then low-pass filtering is indicated. > > These questions about bandwidth and noise- are there any good books > that address this. The three books that I have, in ascending order of difficulty are: "Information Transmission, Modulation and Noise" by Schwartz, "Probability, Random Variables, and Stochastic Processes" by Papoulis, and "Detection, Estimation, and Modulation Theory" by Van Trees. But the one that I hear recommended most often is "Signals and Noise" by Proakis (or something like that). I think if you searched a book site on "signals" and "noise" you'd do well. Stay away from the Van Trees book unless you can take a class and have _lots_ of time. It's very useful, but extremely challenging. It's one of the few books that I have to refer back to constantly, because the material is difficult enough that I just can't remember all of it all the time. > I've actually been picking it up as I go, as I am a > scientist and not an engineer, so just the first step of quantifying > the resolution of our instrument in nm per root hertz (taking the lead > from electrical engineers) was a big step forward in my understanding. > For example, another quesiton I've had in my mind is how to deal with > an attenuated signal, ie, what if I sampled at 50 kHz where the signal > is rolling off due to viscous drag, and tried to compare it to the rest > of my signal. I'm sure this is a really basic concept in electrical > engineering, so maybe someone knows of a book that speaks about > bandwidth and noise and even the fundamental concept of listing noise > in nm per root hertz, and how that works, ie does the distribution of > noise have to be normal or gaussian, does it have to be flat, etc. > > Or maybe there isn't such a book and you could write one? > > Will > > > -- Tim Wescott Wescott Design Services http://www.wescottdesign.com Posting from Google? See http://cfaj.freeshell.org/google/ "Applied Control Theory for Embedded Systems" came out in April. See details at http://www.wescottdesign.com/actfes/actfes.htmlArticle: 111311
No, if a pin is pulled up, it will have a pullup circuit in the schematic, which you can add. The schematic is saying that the pin isn't connected which what that means may well be device dependent. ---Matthew Hicks "scott moore" <nospam@nowhere.com> wrote in message news:SIqdnXM8K7yro9XYnZ2dnUVZ_vSdnZ2d@comcast.com... > Hi, it seems obvious, but I'll ask the question anyways to be sure. > > My dual port ram on a Spartan 3 does not use the rst or ena inputs, nor > have but one clock (clka). On the schematic view, it shows these pins > going nowhere. Can I assume this is "shorthand" for "goes to pullup"? > The documentation on the embedded rams says that pullup of unused inputs > is recommended, because "it takes no routed resources", vs. zero driven > inputs. This implies there is a special bit to pull up right at the > input. Does the unconnected pin on the schematic represent this? > > Thanks, > > Scott MooreArticle: 111312
The main reason I don't instantiate memory primitives is because of the restrictions on address and data types (to SLV). I usually have an integer subtype for the address (the array index when inferring memory), and store anything from integer to enumerated (i.e. state variables) to whole records in them. You can't do that with the primitives, without putting a wrapper around it, and then when you try to examine the contents of the memory during simulation, they're all just bits, and you have to manually convert back to your record, enum, etc. Inferring memory from arrays, especially in applications where the memory is not tied to some sort of pre-existing data and address bus, also allows a more functional descriptive style, rather than an implementation-specific style. I focus on the behavior first, then tweak the implementation to get the performance I need (if any tweaking is needed). The syntesis tools have started recognizing sub-word write enables in inferred memories, which allows inferring memories with wider data paths on the output than the input, now they just need to recognize muxing on the output to allow inferring memories with wider inptuts than outputs. Andy Ray Andraka wrote: > KJ, > > This is actually a fairly common usage model for the Xilinx dual port > RAMs. It lets you, for example store two words per clock on one port and > read them one word per clock on the opposite port at perhaps a faster > clock rate. The data width and address width vary inversely so that > there are always 18k or 16K bits in the memory (18K for the widths that > support the parity bit). For example, if you set one port for 36 bit > width, that port has a depth of 512 words. If you then set the other > port for 18 bit width, it has a 1K depth, and the extra address bit (the > extra bits are added at the lsbs) essentially selects the low or high > half of the 36 bit width for access through the 18 bit port. Similarly, > a 9 bit wide port is 2K deep and accesses a 9 bit slice of that 36 bit > word for each access, with the slice selected with the 2 lsbs of the 9 > bit wide port's address. > > I've found the easiest way to deal with the dual port memories is to > instantiate the primitives. Xilinx has made it far easier with the > virtex 4 which has a common BRAM element for all aspect ratios with > generics on it to define the width. Previously, you needed to > instantiate the specific primitive with the right aspect ratios on each > port. I found it easiest to develop a wrapper for the memory that uses > the width of the address and data to select the BRAM aspect ratio and > instantiate as many as are needed to obtain the data width, that way the > hard work is done just once. This is especially true with the older > style primitives.Article: 111313
I am working on a 'de-serializer' with Xilinx DCM. The single-bit input stream is sampled by an 8X clock. After 8 bits are stored the register, it activates a single-clock 'done' signal to inform the 1X system to retrieve the data. The data, of course, should only be read once. I am thinking using a flag register to interface the two systems. The register is controlled by the 8X clock. The done signal sets the flag and the 1X system resets the flag after read. Since DCM is used, presumably there is no meta-stability issue. Please comment whether this approach is feasible or provide pointer to some reference designs. Thanks in advance. S. C.Article: 111314
Just make sure you NEVER duplicate the one flip-flop that is supposed to synchronize the asynchronous input. Then a 1 ps input delay or set-up time difference can spell disaster. Peter Alfke On Nov 1, 2:32 am, "Ben Jones" <ben.jo...@xilinx.com> wrote: > "Andreas Ehliar" <ehl...@lysator.liu.se> wrote in messagenews:ei8e0q$avt$1@news.lysator.liu.se... > > > > > On 2006-10-31, Ben Jones <ben.jo...@xilinx.com> wrote: > >> In fact, register duplication rarely makes timing better; in fact in many > >> high-performance pipelined designs, it can make it much worse > >> (explanation > >> available on demand). > > > I guess I'll bite and see if my understanding is close to what you have > > in mind: > > > My feeling is that register duplication could worsen a design with > > combinatorial logic followed by a flip flop. This means either that > > the combinatorial logic has to be duplicated (which would enlarge the > > design and perhaps slow down the circuit due to extra routing, or > > by only duplicating the flip flop which will certainly demand extra > > routing since it is normally possible to place a FF directly after a LUT > > using only high speed dedicated routing.Got it in one. The "enlargement" problem isn't much of a problem, since in > FPGA technology if you need to allocate a new register then you basically > get the preceding LUT for free. However, it's the "extra routing" problem > that's the killer. > > > On the other hand, I can't really see that register duplication will make > > the performance much worse (unless the synthesizer makes very bad choices)Say your design is supposed to run at 400MHz (2.5ns clock period). The extra > route from the combinatorial output of the LUT to the input of the "extra" > register added by the replication process may be 500ps. That's 20% of your > cycle budget! Often, it's more like 800ps... of course if your clock speed > is only 100MHz, this is much less of an issue. > > There may be a few scenarios in which register duplication really is a good > thing, but in my experience synthesis tools don't always find them. So I > tend to just leave this "feature" turned off. > > Cheers, > > -Ben- > > (Whoops, off topic...)Article: 111315
In my younger days designing state machines in PALs, we did not have the luxury of pre-synchronizing every asyncrhonous input in its own flop. So we handled asynchronous inputs slightly differently. We constrained the state machine and state mapping such that there was only, ever two destination states based on an asynchronous input at any given time, and both of those destinations had to be adjacent on a K map (for those of you too young to know, that means the two states differed in only one bit, and that one bit becomes the "syncrhonizer"). Sometimes it was in a loop/branch scenario, where one destination was the current state, and one the adjacent next state, or sometimes it was two new destination states, both adjacent to each other. Oddly enough, those two destination states (so long as they are the only possible destinations) don't have to be adjacent to the current state. The primary benefit of this was that the syncrhonizer register could pull extra duty in other parts of the state machine as just another state bit, or even as a syncrhonizer for another input. AND-OR arrays have their advantages when it comes to overcoming glitches due to simultaneous input changes that kill LUT based logic. For example in the Mongo Lander FSM, if Idle and Fire_Retro_Rockets are adjacent states on the Kmap, then the one register that differs between them is the synchronizer, and so long as sufficient timing slack is reserved for MS settling, no separate synchronizer is needed. Note that because other transitions in the state machine are not based on async inputs, they need not be adjacent on the Kmap. In an environment where we had to manually assign state encodings anyway, and registers were at a premium, this technique worked very reliably, so long as there was sufficient slack to allow for MS to settle out (i.e. we did not have the equivalent of a second flop behind the syncrhonizing flop) for a reasonable MTBF. In today's design environment, we rarely manually assign states, and registers are plentiful, so this technique is rarely employed. Also, separately synchronizing asynchronous inputs is more easily auditable in code reviews than the old adjacent-state approach. Andy Brian Davis wrote: > Bob Perlman wrote: > > > > on Halloween night, not a single person dressed as metastability > > showed up at my door for candy > > > > We had four houses' worth of candy-filled bowls lined up on > one long table, which caused many of the evening's spectres > to exhibit distinct signs of metastability during the confectionary > selection process. > > Unlike FPGA's, the resolution time seemed inversely proportional > to the calendar age of the synchronizer :) > > Also, I don't recall anyone mentioning it, but Bob's handy dandy > guide to planetary landing FSM's seems quite topical of late: > > http://www.cambriandesign.com/2006/02/synchronizing-fsm-inputs.html > > BrianArticle: 111316
Are you re-inventing the receive portion of a UART? Peter Alfke On Nov 1, 8:43 am, "fp" <fpga002...@yahoo.com> wrote: > I am working on a 'de-serializer' with Xilinx DCM. The single-bit > input stream is sampled by an 8X clock. After 8 bits are stored the > register, it activates a single-clock 'done' signal to inform the > 1X system to retrieve the data. The data, of course, should only be > read once. > > I am thinking using a flag register to interface the two systems. The > register is controlled by the 8X clock. The done signal sets the flag > and the 1X system resets the flag after read. Since DCM is used, > presumably there is no meta-stability issue. > > Please comment whether this approach is feasible or provide pointer to > some reference designs. > > Thanks in advance. > > S. C.Article: 111317
KJ wrote: > And just exactly which standard interfaces are we talking about? DDRs > have a JEDEC standard but the 'user' side of that DDR controller > doesn't have a standard interface. EXACTLY. The few times I needed an SDRAM interface, I had to write it myself. Everyone has example interface cores and such, but mostly they're tailored to talk to a generic microprocessor bus. If your logic doesn't work that way, then you spend more time fighting the generic back-end interface and it ends up being faster to write the whole module yourself. -aArticle: 111318
Andy, neat idea... Gray-coded counters are popular for the same reason. Peter Alfke On Nov 1, 9:13 am, "Andy" <jonesa...@comcast.net> wrote: > In my younger days designing state machines in PALs, we did not have > the luxury of pre-synchronizing every asyncrhonous input in its own > flop. > > So we handled asynchronous inputs slightly differently. > > We constrained the state machine and state mapping such that there was > only, ever two destination states based on an asynchronous input at any > given time, and both of those destinations had to be adjacent on a K > map (for those of you too young to know, that means the two states > differed in only one bit, and that one bit becomes the "syncrhonizer"). > Sometimes it was in a loop/branch scenario, where one destination was > the current state, and one the adjacent next state, or sometimes it was > two new destination states, both adjacent to each other. Oddly enough, > those two destination states (so long as they are the only possible > destinations) don't have to be adjacent to the current state. > > The primary benefit of this was that the syncrhonizer register could > pull extra duty in other parts of the state machine as just another > state bit, or even as a syncrhonizer for another input. AND-OR arrays > have their advantages when it comes to overcoming glitches due to > simultaneous input changes that kill LUT based logic. > > For example in the Mongo Lander FSM, if Idle and Fire_Retro_Rockets are > adjacent states on the Kmap, then the one register that differs between > them is the synchronizer, and so long as sufficient timing slack is > reserved for MS settling, no separate synchronizer is needed. Note that > because other transitions in the state machine are not based on async > inputs, they need not be adjacent on the Kmap. > > In an environment where we had to manually assign state encodings > anyway, and registers were at a premium, this technique worked very > reliably, so long as there was sufficient slack to allow for MS to > settle out (i.e. we did not have the equivalent of a second flop > behind the syncrhonizing flop) for a reasonable MTBF. > > In today's design environment, we rarely manually assign states, and > registers are plentiful, so this technique is rarely employed. Also, > separately synchronizing asynchronous inputs is more easily auditable > in code reviews than the old adjacent-state approach. > > Andy > > Brian Davis wrote: > > Bob Perlman wrote: > > > > on Halloween night, not a single person dressed as metastability > > > showed up at my door for candy > > > We had four houses' worth of candy-filled bowls lined up on > > one long table, which caused many of the evening's spectres > > to exhibit distinct signs of metastability during the confectionary > > selection process. > > > Unlike FPGA's, the resolution time seemed inversely proportional > > to the calendar age of the synchronizer :) > > > Also, I don't recall anyone mentioning it, but Bob's handy dandy > > guide to planetary landing FSM's seems quite topical of late: > > > http://www.cambriandesign.com/2006/02/synchronizing-fsm-inputs.html > > > BrianArticle: 111319
Peter Alfke wrote: > KJ, You like standards. > We just finished implementing PCIexpress. When I look at the complexity > of that standard, I just cringe. I cannot fathom why one needs so much > stuff to communicate data. But then I am old frugal and basic guy who > believes in simplicity. It's designed to ease the job of the person writing the host driver, and, more important, the end user stuffing the card into his no-name PC. Making an interface generic enough to be usable over a wide range of disparate uses isn't trivial. USB and FireWire are the same way: complexity for the engineers allows simplicity for the users. You'd rather we go back to jumpers or DIP switches for I/O card base address select? Why should the end user care about where the card lives in the address space? -aArticle: 111320
Peter Alfke wrote: > Are you re-inventing the receive portion of a UART? > Peter Alfke > > On Nov 1, 8:43 am, "fp" <fpga002...@yahoo.com> wrote: > > I am working on a 'de-serializer' with Xilinx DCM. The single-bit > > input stream is sampled by an 8X clock. After 8 bits are stored the > > register, it activates a single-clock 'done' signal to inform the > > 1X system to retrieve the data. The data, of course, should only be > > read once. > > > > I am thinking using a flag register to interface the two systems. The > > register is controlled by the 8X clock. The done signal sets the flag > > and the 1X system resets the flag after read. Since DCM is used, > > presumably there is no meta-stability issue. > > > > Please comment whether this approach is feasible or provide pointer to > > some reference designs. > > > > Thanks in advance. > > > > S. C. In UART, the system clock rate is much higher than the serial input and the system can do 'oversampling'. The situation is reverse in my application, in which the serial input rate is much higher (and that's why a DFS and 8X clock is used).Article: 111321
On 2006-11-01, aravind <aramosfet@gmail.com> wrote: > does your design support only 44.1khz ?if yes what modifications have > to be done to support 48khz Yes, it's hard-wired (is that the right term for a CPLD?) to 44.1KHz timing. To do other rates would require changes to the biphase decoder thresholds at least, the rest should just follow the signal timing. -- Ian "Tamahome!!!" - "Miaka!!!"Article: 111322
On 1 Nov 2006 09:13:16 -0800, "Andy" <jonesandy@comcast.net> wrote: >In my younger days designing state machines in PALs, we did not have >the luxury of pre-synchronizing every asyncrhonous input in its own >flop. > >So we handled asynchronous inputs slightly differently. > >We constrained the state machine and state mapping such that there was >only, ever two destination states based on an asynchronous input at any >given time, and both of those destinations had to be adjacent on a K >map (for those of you too young to know, that means the two states >differed in only one bit, and that one bit becomes the "syncrhonizer"). I mentioned alternate coding techniques in the Q and A. One of the problems with devising examples to illustrate a principle is that they have to be simple enough for the newcomer to comprehend, which means that they're likely to be amenable to alternate techniques that you might not want to use generally. <good stuff snipped> >In today's design environment, we rarely manually assign states, and >registers are plentiful, so this technique is rarely employed. Also, >separately synchronizing asynchronous inputs is more easily auditable >in code reviews than the old adjacent-state approach. Agreed. And making the code more easily auditable (or just more comprehensible to the person who takes it over years from now) is a valuable safety tip. To paraphrase something Peter said a while back, flip-flops and gates are cheap, but problems are expensive. Bob Perlman Cambrian Design Works http://www.cambriandesign.comArticle: 111323
Uwe Bonnes wrote: > Jon Elson <elson@pico-systems.com> wrote: > >>Spartan XL is not the 5 V Spartan, it is 3.3 V, and not pin compatible >>with 5 V Spartan. These chips will not work without major changes to >>the board. I am doing that, but going to XCS2E. It is a complete >>from-scratch redesign. > > > Consider using XC3S...E. > Why stick with XCS2E? My reasoning, at the time this redesign started was based partly on price, the I/O voltages supported, and the size of the ROM needed to download the FPGA. This product has no CPU or other ROM on board. I finally figured out how to use an SST serial flash memory that is incredibly cheap. 1 Mbit for $1.85, and it takes 2 little CMOS chips to get the ROM to start dumping its contents. Maybe I made a mistake, but this product uses a pretty small FPGA by today's standards. I can get the XC2S50-something-TQ144C for $12, I know how to mount it to a board myself, etc. A number of the newer stuff is in packages I at least am not so sure I can handle. JonArticle: 111324
Mike Harrison wrote: > On Wed, 01 Nov 2006 00:20:36 GMT, "John_H" <newsgroup@johnhandwork.com> wrote: > > >>"Uwe Bonnes" <bon@hertz.ikp.physik.tu-darmstadt.de> wrote in message >>news:ei8iuu$elg$1@lnx107.hrz.tu-darmstadt.de... >> >>>Peter Alfke <peter@xilinx.com> wrote: >>> >>>>Have you tried the distributors, including DigiKey? >>>>Peter Alfke >>> >>>For the 5 Volt Xilinx series, none of the part is on stock at Digi, >>>and all have quite high minimum order >>> >>>-- >>>Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de >>> >>>Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt >>>--------- Tel. 06151 162516 -------- Fax. 06151 164321 ---------- >> >> >> >>XCS30XL-4TQG144I (or C) are both in stock at Digikey but the -3 speed grades >>have the 60pc minimum order. Can you get by with the different speed grade? >> > > Have you tried www.findchips.com ? plenty of hits on a search for XC2S -is this the correct family? > No. The part is XCS30-3TQ144C, and findchips says - go to Digi-Key, where this thread started. I have no problem obtaining Spartan 2E, I need the original Spartan 5V chips. You have to be careful of these "web hits". I had another oddball part, a TI DAC chip that was on 50-week backorder. I did a web search, and outfits like USBid showed tens of thousands of parts in stock at their partner's warehouses. When I actually called them, they told me the ONLY parts available in the entire world were in a warehouse in Russia, and the guy wanted $60 a piece, minimum quantity 100 pieces! I had to take salvaged parts in that case. So, just because these outfits LIST a part on the web does not really mean they actually even have access to that part! Jon
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