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
On Thu, 9 Dec 2010 18:12:46 -0800 (PST), rickman <gnuarm@gmail.com> wrote: >On Dec 8, 3:16 pm, Vaughn <vaughnb...@gmail.com> wrote: >> Replaying to the question below: >> >> > Does Altera check hold times? >> >> Yes, Altera tools check hold times. We check all timing constraints: >> setup & hold, plus the asynchronous reset equivalents (recovery & >> removal) at all timing corners (3 in our latest devices), with on-die >> variation and jitter models applied at each corner. The corners cover >> large, correlated variation, while the "within corner" min/max >> variation and clock uncertainty models cover less correlated variation >> and timing jitter. >> >> If TimeQuest says it works, and you have properly timing constrained >> the design, it will be robust. >> >> Regards, >> >> Vaughn Betz >> Altera > >Not trying to pick on Altera as I think this is a problem with all >vendors' products. But how do you verify that your timing constraints >are correct? It is easy to say that any part of a design will be >correct if you have done your design work right. But 90% of >engineering is making sure that it is correct. There are many >different methods, techniques and tools to assist the process of >verification for nearly every aspect of design work. I don't know of >any that will verify that your design is properly constrained for >timing. > >I have never figured out why no one seems to see this as a problem. >Is there something I am missing? Maybe yes, maybe no. The simple fact is that if you design fully synchronous systems with single clock, the only additional constraint(s) to clock period you need are the external IO timing. For most of the designs setting the clock period(s) is enough to constrain all of your design (and with a DCM setting the period of the input clock is enough most of the time too). If, on the other hand, you have asynchronous clocks and/or resets, multi-cycle paths, ripple clocks then you need to pay extra attention. There are several tools which check for each of these conditions and verify the timing constraints you set in flow but these tools are quite expensisve and mostly (only?) used in ASIC flow. For FPGAs most people seem to ignore these conditions and use the silicon to test their designs. I am amazed that some people don't even simulate their designs and go from editor to bit file directly and test on hardware. -- Muzaffer Kal DSPIA INC. ASIC/FPGA Design Services http://www.dspia.comArticle: 150076
On 12/9/2010 11:50 AM, Gabor wrote:
> On Dec 9, 11:02 am, "j."<garas....@gmail.com> wrote:
>> Given a Data Link that uses DS92LV1021 chip (16-40MHz 10-bit bus LVDS
>> Serializer) to send data. Unfortunately it also sends start and stop
>> bits, 12-bit each word total (@480MHz). Task is to build a receiver in
>> FPGA. However, both Xilinx and Altera built-in SERDES circuits support
>> only 10-bit words ("deserialization factor"). Is there any way to
>> interface them with the above DS92LV1021 chip?
>
> Many of the newer Xilinx chips can do deserialization at these rates
> using standard
> I/O's rather than the "GTP" or "Rocket I/O". I expect newer Altera
> parts can do the
> same. For Xilinx there are some app notes on "high-speed LVDS" you
> can look for
> on their site.
>
> -- Gabor
Be careful here, this chip embeds the clock in the data stream. In
other words, it does not send a separate synchronous clock along with
the serialized data.
You will be forced into an FPGA that has something like a DPA (dynamic
phase aligner) to find the eye of the data and extract a clock.
Typically it is the higher end family of FPGA's that offer these types
of interfaces, but they come with a high price tag.
It might just be more cost effective to use the receiver chip by
National and go into your FPGA with parallel data. You could then
easily get into a very cost effective FPGA.
Rob
Article: 150077On Dec 9, 10:04=A0pm, Muzaffer Kal <k...@dspia.com> wrote: > On Thu, 9 Dec 2010 18:12:46 -0800 (PST), rickman <gnu...@gmail.com> > wrote: > > > > >On Dec 8, 3:16 pm, Vaughn <vaughnb...@gmail.com> wrote: > >> Replaying to the question below: > > >> > Does Altera check hold times? > > >> Yes, Altera tools check hold times. We check all timing constraints: > >> setup & hold, plus the asynchronous reset equivalents (recovery & > >> removal) at all timing corners (3 in our latest devices), with on-die > >> variation and jitter models applied at each corner. The corners cover > >> large, correlated variation, while the "within corner" min/max > >> variation and clock uncertainty models cover less correlated variation > >> and timing jitter. > > >> If TimeQuest says it works, and you have properly timing constrained > >> the design, it will be robust. > > >> Regards, > > >> Vaughn Betz > >> Altera > > >Not trying to pick on Altera as I think this is a problem with all > >vendors' products. =A0But how do you verify that your timing constraints > >are correct? =A0It is easy to say that any part of a design will be > >correct if you have done your design work right. =A0But 90% of > >engineering is making sure that it is correct. =A0There are many > >different methods, techniques and tools to assist the process of > >verification for nearly every aspect of design work. =A0I don't know of > >any that will verify that your design is properly constrained for > >timing. > > >I have never figured out why no one seems to see this as a problem. > >Is there something I am missing? > > Maybe yes, maybe no. The simple fact is that if you design fully > synchronous systems with single clock, the only additional > constraint(s) =A0to clock period =A0you need are the external IO timing. That's a pretty big simplification. The fact that you have a single clock does not mean that your entire design runs in one clock cycle. One of the trickier parts of timing constraints is getting the right clock timing applied to the right sections of logic in a design. In any given design I have large amounts of logic that run at many clock cycles multiples. If I try to spec these multi-clock sections I run the risk of under-constraining some part of the design I didn't intend to apply that constraint to. To the best of my knowledge there is no way to verify that my timing constraints are correct. > For most of the designs setting the clock period(s) is enough to > constrain all of your design (and with a DCM setting the period of the > input clock is enough most of the time too). > If, on the other hand, you have asynchronous clocks and/or resets, > multi-cycle paths, ripple clocks then you need to pay extra attention. "Pay extra attention"... that is what it is all about. I can pay tons of attention, but I make mistakes... even when I'm not posting to newsgroups late at night. The hard part of engineering is figuring out ways of catching those mistakes. I am talking about the nearly total lack of verification of timing constraints. Bad constraints can create some of the worst intermittent bugs you have ever seen. > There are several tools which check for each of these conditions and > verify the timing constraints you set in flow but these tools are > quite expensisve and mostly (only?) used in ASIC flow. For FPGAs most > people seem to ignore these conditions and use the silicon to test > their designs. I am amazed that some people don't even simulate their > designs and go from editor to bit file directly and test on hardware. I've never seen any of these tools, but maybe that's because I work with FPGAs. Testing timing in silicon is not a very good way to verify constraints. To properly test timing you would need to get your hands on the slowest chips that meet the specs, drop the power supply voltage to the minimum level and then heat them up to the max operating temp. Only then can you say your timing is correct by testing. I had to do this once when I worked with routing and timing tools that didn't properly estimate timing... we suspected on high fanout nets. Even when the tools said we met timing, the design could fail on the bench and guess what made them work... cold spray! The vendor suspected... guess what... our timing constraints! We bought a chip heater and tested at elevated temp with a lowered Vdd and used the worst speed chips we could find. The product shipped, but only after many long weeks of over time! As to not simulating, that is the lazy man carrying the heavy load. They think it will be fewer trips, but in the end it costs dearly. I am mostly satisfied that my designs work perfectly (except for spec errors) when I try them on the bench. Simulation just makes life so much easier! In fact, my simulations are as complex as the design being tested! RickArticle: 150078
On 9 Dez., 17:02, "j." <garas....@gmail.com> wrote:
> Given a Data Link that uses DS92LV1021 chip (16-40MHz 10-bit bus LVDS
> Serializer) to send data. Unfortunately it also sends start and stop
> bits, 12-bit each word total (@480MHz). Task is to build a receiver in
> FPGA. However, both Xilinx and Altera built-in SERDES circuits support
> only 10-bit words ("deserialization factor"). Is there any way to
> interface them with the above DS92LV1021 chip?
The 12 bit word length is a non issue: use a 6x deserializer. You get
your 12 bit word as two 6 bit nibbles. Piece of cake.
However, the clock recovery that the other poster talks about is more
difficult.
Without a PLL or other specialized support circuitry you would need 3x
oversampling to recover the clock and phase reliably in a digital
circuit.
Therefore you end up at 1440Mbps, which is just out of reach for a
virtex-5 (710MHz fmax = 1420Mbps).
With 103% VCC you should be OK on a virtex-5.
Kolja
Article: 150079Thank you for the answers. > Be careful here, this chip embeds the clock in the data stream. =A0In > other words, it does not send a separate synchronous clock along with > the serialized data. Actually, AFAIK this "embedded clock" is indeed derived from the start-stop bit. To get synchronized the transmitter needs to issue some kind of synchronization pattern, I can imagine simply "all ones". In this case the stop bit is the only zero in the data stream, can be used to start synchronization. > You will be forced into an FPGA that has something like a DPA (dynamic > phase aligner) to find the eye of the data and extract a clock. > Typically it is the higher end family of FPGA's that offer these types > of interfaces, but they come with a high price tag. In my case the situation is a bit easier, both the transmitter and the receiver uses the same clock source, thus the frequency is always the same, the phase might be different (even for the data channels, as the wires have slightly different length) but constant. Thus if the correct phase has been established it remains correct. Of course in presence of a considerable jitter the phase needs to get realigned in some way. > It might just be more cost effective to use the receiver chip by > National and go into your FPGA with parallel data. =A0You could then > easily get into a very cost effective FPGA. The problem is that the FPGA should receive data from 96 similar 10:1 LVDS Channels. There is no board space for 96 National chips. In addition no FPGA has 96 independent embedded PLLs. JanosArticle: 150080
"j." <garas.rez@gmail.com> writes:
> Given a Data Link that uses DS92LV1021 chip (16-40MHz 10-bit bus LVDS
> Serializer) to send data. Unfortunately it also sends start and stop
> bits, 12-bit each word total (@480MHz). Task is to build a receiver in
> FPGA. However, both Xilinx and Altera built-in SERDES circuits support
> only 10-bit words ("deserialization factor"). Is there any way to
> interface them with the above DS92LV1021 chip?
I have done this for a very similar link (just in LUTs) in a Spartan3E
at 27MHz, IIRC it would probably go to 30ish MHz - pushing it to 40MHz
would be beyond it.
I also had the benefit of enough control of the system to get it to
send a series of all-zeros words at startup which made finding the
sampling point much easier!
Cheers,
Martin
--
martin.j.thompson@trw.com
TRW Conekt - Consultancy in Engineering, Knowledge and Technology
http://www.conekt.co.uk/capabilities/39-electronic-hardware
Article: 150081
On 10 Dez., 09:52, Kolja Sulimma <ksuli...@googlemail.com> wrote:
> On 9 Dez., 17:02, "j." <garas....@gmail.com> wrote:
>
> > Given a Data Link that uses DS92LV1021 chip (16-40MHz 10-bit bus LVDS
> > Serializer) to send data. Unfortunately it also sends start and stop
> > bits, 12-bit each word total (@480MHz). Task is to build a receiver in
> > FPGA. However, both Xilinx and Altera built-in SERDES circuits support
> > only 10-bit words ("deserialization factor"). Is there any way to
> > interface them with the above DS92LV1021 chip?
>
> The 12 bit word length is a non issue: use a 6x deserializer. You get
> your 12 bit word as two 6 bit nibbles. Piece of cake.
> However, the clock recovery that the other poster talks about is more
> difficult.
> Without a PLL or other specialized support circuitry you would need 3x
> oversampling to recover the clock and phase reliably in a digital
> circuit.
> Therefore you end up at 1440Mbps, which is just out of reach for a
> virtex-5 (710MHz fmax = 1420Mbps).
> With 103% VCC you should be OK on a virtex-5.
>
> Kolja
We are successfully deserializing a 60MWord/s (720Mbps) data-stream
with a Cyclone III by using DPA. However, it is tricky and we do also
not achieve the same cable-length as with the National deserializer
(but reasonable lengths). So if there is no real requirement (cost,
space) to get rid of the external deserializer, it will be the easier
option to use the dedicated chip.
Thomas
www.entner-electronics.com
Article: 150082On 10 Dez., 11:50, "j." <garas....@gmail.com> wrote: > In my case the situation is a bit easier, both the transmitter and > the receiver uses the same clock source, thus the frequency > is always the same, the phase might be different (even for > the data channels, as the wires have slightly different length) > but constant. Thus if the correct phase has been established > it remains correct. > This should make things much easier, especially if you have the same routing-delay on all channels. It would be difficult if you have to sample the channels all on a different phase (maybe you could adjust the phase on the transmitter side). Thomas www.entner-electronics.comArticle: 150083
jonpry <jonpry@gmail.com> wrote: >> Cant say I am a great fan of MIG. The design seems incredibly bloated and >> not very easy to get to run at a reasonable speed. I ended up writing my >> own DDR2 controller. >> You should check that MIG and the device allows you to run at such a slow >> speed. You really need a good simulation to start with all timings >> verified. Check the datasheet to verify that no timings are being violated. >> Can you not look at the data on a scope to see if you are getting the >> correct signals and verify timing? Memory can be a pain to get working so >> you need to be as meticulous as possible. > >The MIG controller is a bit complicated, but it does appear to be the >correct architecture for LPDDR parts. On the scope I can see that the >memory is indeed working properly, so its timings must be fine. >Whether or not the memory is meeting the fpga's timing is a different >story. MIG is way too bloated especially on Spartan devices. >I've managed to confirm that what is happening in simulation when >clock is slower than 12ns, is indeed what is happening in hardware at >any speed from 10 to 100 mhz. I guess I will need to rewrite the dqs >fifo enable stuff. I think if dqs comes after some margin the logic is >just broken and won't turn off. > >> They do _not_ have delay-locked >> loops in them, so read timing almost works better using your internal >> clock than the DQS signal. > >This argument seems backwards to me. There is almost no point on using >DQS on regular DDR parts because the the DLL phase aligns it to the >master clock, giving you a multitude of good options. But with no DLL, >there is no phase guarantee, forcing you to use a truly source >synchronous design. There is a phase quarantee (if you clock the memory from the FPGA) but you need to calculate it by yourself. On a Spartan 3e you should be able to achieve 100 to 125MHz depending on the speed grade. An added bonus of writing your own DDR controller is that you can use any I/O pin to connect the memory. -- Failure does not prove something is impossible, failure simply indicates you are not using the right tools... nico@nctdevpuntnl (punt=.) --------------------------------------------------------------Article: 150084
On 8 Dez., 20:10, Alessandro Basili <alessandro.bas...@cern.ch> wrote: > after some struggles I have eventually found the time to revive an old > project on opencores which hasn't been updated since a while: > > a spacewire link and router. > [..] > > Any feedback is appreciated. I think spacewire is not the best example for open cores (At least unless you manage to get ESA as co-supporter which is unlikely as ESA has allready spacewire cores). Open cores tend to have a lack in documentation and verification, which is a no-go for developing space electronics. Even if you target on public science projects it is very likely that you need to ensure the "space-readiness" in many aspects for a core before you can use it. For spacewire interface I consider the effort to proof the quality of a core clearly exceeding the effort for writting the core for your own. Are you firm with developing according to ECSS-Q 60 02? I would expect a core development to be complaint to this before using it without further quality checking in case of the core not beeing provided from ESA for a ESA project. In case of detailed questions you may also conntact me by sending an email. You should change the receive-address to thomas @domain_from_email when replying. best regards ThomasArticle: 150085
> There is a phase quarantee (if you clock the memory from the FPGA) but > you need to calculate it by yourself. On a Spartan 3e you should be > able to achieve 100 to 125MHz depending on the speed grade. An added > bonus of writing your own DDR controller is that you can use any I/O > pin to connect the memory. My board is not fully assembled yet. Normally the clock would be supplied from the PLL's in an omap3 processor. But it is not populated yet, so I am supplying the clock from off board. Living in the third world, there is a shortage of clock sources at hand. I have a 50mhz oscillator, and whatever i can synthesize on another fpga board. The synthetic clocks do not seem to work at even 50mhz. So I'm going to put off further speed testing until the clocking situation improves. It may work for all I know. everything looks fine on the scope at 100mhz anyways.Article: 150086
I just have 1 fast LVDS data line. I need to have 10 bits of data
in a register , every 5 clock cycles(DDR), coming from only 1
differential data line.
Dear Gurus,
1- Can I deserialize a 240 Mhz , LVDS, DDR input coming data using a
10:1 serdes ratio. (clk is also LVDS)
2- I want to do it with data width = 1( D = 1), is it possible?
3- Do I have to put delay to clk inputs. If not why is there a delay
element (IODELAY2) in xapp1064.pdf
4- Do I have to use the pll concept. Is there any other solution?
5- In the documentation of spartan 6 deserialization 16:1 is shown
but with a SDR rate. Can it be changed to DDR?
=================================================================
PS1: I am using Spartan 6, slx100, -3
PS2: I checked xapp1064.pdf, ug381.pdf, ds162.pdf. I need more info
on IODELAY2 and ISERDES2.
best regards
Serkan
Article: 150087I found this thread when searching for a way to find a latch in my design. I discovered another very easy way to find latches in 10.1 of ISE. I placed and routed my design and then ran PlanAhead. Go to Edit -> Find, and choose "Instances". The criteria should be "Type" "is" "Latch". It found the latch in the blink of an eye. Turned out to be a Chipscope ILA that had a latch in it. Greg --------------------------------------- Posted through http://www.FPGARelated.comArticle: 150088
jonpry <jonpry@gmail.com> wrote: >> There is a phase quarantee (if you clock the memory from the FPGA) but >> you need to calculate it by yourself. On a Spartan 3e you should be >> able to achieve 100 to 125MHz depending on the speed grade. An added >> bonus of writing your own DDR controller is that you can use any I/O >> pin to connect the memory. > >My board is not fully assembled yet. Normally the clock would be >supplied from the PLL's in an omap3 processor. But it is not populated >yet, so I am supplying the clock from off board. Living in the third >world, there is a shortage of clock sources at hand. I have a 50mhz >oscillator, and whatever i can synthesize on another fpga board. The >synthetic clocks do not seem to work at even 50mhz. So I'm going to >put off further speed testing until the clocking situation improves. >It may work for all I know. everything looks fine on the scope at >100mhz anyways. Why aren't you using the clock multipliers in the Spartan3e? You can feed it almost any clock you want and create any clock frequency you need. If the memory is connected to the FPGA, you should also clock the memory from the FPGA. This eliminates the clock input to the clock net timing uncertainty. -- Failure does not prove something is impossible, failure simply indicates you are not using the right tools... nico@nctdevpuntnl (punt=.) --------------------------------------------------------------Article: 150089
> Why aren't you using the clock multipliers in the Spartan3e? You can > feed it almost any clock you want and create any clock frequency you > need. If the memory is connected to the FPGA, you should also clock > the memory from the FPGA. This eliminates the clock input to the clock > net timing uncertainty. Mainly because the MIG design requires a CLK90, and there is no CLKFX90. I think this is the root of the trouble. If I use a synthetic clock from another fpga, it has DLL jitter in it, and although the DLL in my design seems to stay locked for a few seconds while running on such a source, things seem to not work quite right for that period of time. The memory is being clocked from the fpga, just I can't get a low jitter input at anything other than 50mhz right now.Article: 150090
On Dec 10, 1:46=A0pm, jonpry <jon...@gmail.com> wrote: > > Why aren't you using the clock multipliers in the Spartan3e? You can > > feed it almost any clock you want and create any clock frequency you > > need. If the memory is connected to the FPGA, you should also clock > > the memory from the FPGA. This eliminates the clock input to the clock > > net timing uncertainty. > > Mainly because the MIG design requires a CLK90, and there is no > CLKFX90. I think this is the root of the trouble. If I use a synthetic > clock from another fpga, it has DLL jitter in it, and although the DLL > in my design seems to stay locked for a few seconds while running on > such a source, things seem to not work quite right for that period of > time. > > The memory is being clocked from the fpga, just I can't get a low > jitter input at anything other than 50mhz right now. I forgot to mention that for a time I tried cascaded DCM's in the one fpga, but was not able to get it lock. Presumably I just did something wrong, it was just easier to debug with the DLL's in different chips because I am able to have a bank of different frequencies, and I just plug in the wire and see what happens. Now that it is generally working I suppose I could try cascaded DCM's again.Article: 150091
On Dec 10, 5:04=A0pm, jonpry <jon...@gmail.com> wrote: > On Dec 10, 1:46=A0pm, jonpry <jon...@gmail.com> wrote: > > > > Why aren't you using the clock multipliers in the Spartan3e? You can > > > feed it almost any clock you want and create any clock frequency you > > > need. If the memory is connected to the FPGA, you should also clock > > > the memory from the FPGA. This eliminates the clock input to the cloc= k > > > net timing uncertainty. > > > Mainly because the MIG design requires a CLK90, and there is no > > CLKFX90. I think this is the root of the trouble. If I use a synthetic > > clock from another fpga, it has DLL jitter in it, and although the DLL > > in my design seems to stay locked for a few seconds while running on > > such a source, things seem to not work quite right for that period of > > time. > > > The memory is being clocked from the fpga, just I can't get a low > > jitter input at anything other than 50mhz right now. > > I forgot to mention that for a time I tried cascaded DCM's in the one > fpga, but was not able to get it lock. Presumably I just did something > wrong, it was just easier to debug with the DLL's in different chips > because I am able to have a bank of different frequencies, and I just > plug in the wire and see what happens. Now that it is generally > working I suppose I could try cascaded DCM's again. Cascading DCM's does not work particularly well. There is more jitter on the FX outputs of the DCM's than the CLK0, 90, 2X outputs. The second DCM therefore ends up with a jittery input clock. If you want to try cascading at 100 Mhz, just use the CLK2X output of the first DCM to get a somewhat less jittery 100 Mhz and feed that into the DCM for the 90 degree shift. Unfortunately the Spartan 3 series don't have PLL's, which would be a better choice for frequency synthesis. Regards, GaborArticle: 150092
On 10 Dez., 12:08, Thomas Entner <thomas.entne...@gmail.com> wrote: > On 10 Dez., 11:50, "j." <garas....@gmail.com> wrote: > > > In my case the situation is a bit easier, both the transmitter and > > the receiver uses the same clock source, thus the frequency > > is always the same, the phase might be different (even for > > the data channels, as the wires have slightly different length) > > but constant. Thus if the correct phase has been established > > it remains correct. > > This should make things much easier, especially if you have the same > routing-delay on all channels. It would be difficult if you have to > sample the channels all on a different phase (maybe you could adjust > the phase on the transmitter side). If the FPGA has access to the clock source of the serializer, only the phase has to be determined at the receiver. That is actually pretty easy if you can set the transmitter to a know training pattern. If you have a CPU in your system you can write software that controls the variable phase shift of an IDELAY to search for the right phase. This can be done one input at a time. Once you know the correct delay setting for your 96 inputs your are good to go. At 480Mbps there is not much to worry about. We do that at 1250Mbps and have a reliable sampling window of quite a few delay taps. Kolja cronologic.deArticle: 150093
jonpry <jonpry@gmail.com> wrote: >> Why aren't you using the clock multipliers in the Spartan3e? You can >> feed it almost any clock you want and create any clock frequency you >> need. If the memory is connected to the FPGA, you should also clock >> the memory from the FPGA. This eliminates the clock input to the clock >> net timing uncertainty. > >Mainly because the MIG design requires a CLK90, and there is no >CLKFX90. I think this is the root of the trouble. If I use a synthetic ???? Read the spartan3e datasheet and user manual. The DCM has 90, 180 and 270 degrees phase shift outputs and the ability to shift these clocks by small steps as well. >clock from another fpga, it has DLL jitter in it, and although the DLL >in my design seems to stay locked for a few seconds while running on >such a source, things seem to not work quite right for that period of >time. The DLL jitter is somewhere around 100ps p-p maximum. If your design fails by that marging you better not start producing it. The FPGA is quite tolerant to input jitter BTW. Your problem sounds like the pulses from your clock source are not wide enough or otherwise distorted. Get a >400MHz scope and check whether pulse widths and rise times are within the specs the FPGA requires. >The memory is being clocked from the fpga, just I can't get a low >jitter input at anything other than 50mhz right now. You can cascade DCMs as well but you should read the Xilinx application notes to get it right. -- Failure does not prove something is impossible, failure simply indicates you are not using the right tools... nico@nctdevpuntnl (punt=.) --------------------------------------------------------------Article: 150094
On Wed, 1 Dec 2010 13:16:19 -0800 (PST), Sink0 <sink00@gmail.com> wrote: >> >> As a note, while I haven't done any Linux driver development our former >> programmer did. He said that LDD 3rd ed. is chock full o' both errata >> and things that were only true under the 2.4 kernel, not 2.6. >> >> -- >> Rob Gaddi, Highland Technology >> Email address is currently out of order- Hide quoted text - >> >> - Show quoted text - > >Haha thank you for the information. Can you point me any other good >reference? Other than the drivers already placed on the linux? You still need LDD, because it has a different perspective. But a better book by far for 2.6 kernels is "Essential Linux Device Drivers" by Venkateswaran. - BrianArticle: 150095
Serkan wrote: > I just have 1 fast LVDS data line. I need to have 10 bits of data > in a register , every 5 clock cycles(DDR), coming from only 1 > differential data line. > > Dear Gurus, > > 1- Can I deserialize a 240 Mhz , LVDS, DDR input coming data using a > 10:1 serdes ratio. (clk is also LVDS) 240 MHz shouldn't be a problem for the Spartan 6 pins. > 2- I want to do it with data width = 1( D = 1), is it possible? What's your question? Input or Output datawidth? From my understanding you want a 1 bit input (240 MBit/s) deserialized to 10 bit (@24 MBit/s) output, right? Don't see any reason why this shouldn't work. > 3- Do I have to put delay to clk inputs. If not why is there a delay > element (IODELAY2) in xapp1064.pdf What's the protocol you use for clock recovery/synchronization? > 4- Do I have to use the pll concept. Is there any other solution? Have a look at http://www.missinglinkelectronics.com/files/papers/MLE-TB20091127.pdf and XAPP224 respectively. You will need some reference clock, and you will have to use a PLL or DCM somewhere in the system, to generate the right clock(s) from that reference. > 5- In the documentation of spartan 6 deserialization 16:1 is shown > but with a SDR rate. Can it be changed to DDR? So again: what's the point here? I still don't get what you are trying to do, but you might also be interested in XAPP460, LorenzArticle: 150096
rickman wrote:
> On Dec 2, 10:32 am, Jan Decaluwe <j...@jandecaluwe.com> wrote:
>> rickman wrote:
>>
>> Of course, I'm sure this is all obvious to you and I realize that
>> it must have been my explanation that was inadequate. But there
>> really was no need for this confusion. You could have seen all
>> these things for yourself by just spending one minute to see
>> the screencast. Sigh.
>
> I don't know what a screencast is
I'll hold your hand:
http://en.wikipedia.org/wiki/Screencast
> and I have never seen a sales tool
> that conveyed any useful info in 1 minute.
Look, I can assure you that many good engineers find such a
screencast very useful. I am also of the opinion that the
people who make such things, for people like you, through
hard work, deserve much better than this. Your prejudices
are so high that you don't even want to *try*, even though
it takes only a fraction of the time you spend on writing
posts with a much lower information content. Beats me.
Time to review good old school engineering practices.
--
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
Python as a HDL: http://www.myhdl.org
VHDL development, the modern way: http://www.sigasi.com
Analog design automation: http://www.mephisto-da.com
World-class digital design: http://www.easics.com
Article: 150097>On Wed, 1 Dec 2010 13:16:19 -0800 (PST), Sink0 <sink00@gmail.com> wrote: > >>> >>> As a note, while I haven't done any Linux driver development our former >>> programmer did. �He said that LDD 3rd ed. is chock full o' both errata >>> and things that were only true under the 2.4 kernel, not 2.6. >>> >>> -- >>> Rob Gaddi, Highland Technology >>> Email address is currently out of order- Hide quoted text - >>> >>> - Show quoted text - >> >>Haha thank you for the information. Can you point me any other good >>reference? Other than the drivers already placed on the linux? > >You still need LDD, because it has a different perspective. But a better book by >far for 2.6 kernels is "Essential Linux Device Drivers" by Venkateswaran. > >- Brian > Hmm thank you! I just got that on my hands right now i will start reading it as soon as possible.. end of year is always a hell haha.. --------------------------------------- Posted through http://www.FPGARelated.comArticle: 150098
On Dec 7, 12:56=A0am, Gabor <ga...@alacron.com> wrote: > On Dec 6, 12:06=A0pm, d_s_klein <d_s_kl...@yahoo.com> wrote: > > > On Dec 6, 3:13=A0am, Mike Harrison <m...@whitewing.co.uk> wrote: > > > >http://www.youtube.com/watch?v=3Dh_USk-HNgPA&feature=3Dplayer_detailpa= ge > > > > Come on X and A - spice up your promo =A0videos! > > > Everybody chooses what is important to them. =A0Some like snazzy videos= , > > some like to ship product to customers... > > Well, then Lattice is doing both. =A0Their policy on new part > announcement is to wait until they have at least _some_ silicon available= . =A0Xilinx is > already announcing Virtex 8 while not shipping V7. well this time Lattice has broken thee policy, there are no MachXO parts shipping? AnttiArticle: 150099
Kolja Sulimma <ksulimma@googlemail.com> writes: > If the FPGA has access to the clock source of the serializer, only the > phase has > to be determined at the receiver. That is actually pretty easy if you > can set the transmitter > to a know training pattern. > If you have a CPU in your system you can write software that controls > the variable > phase shift of an IDELAY to search for the right phase. This can be > done one input > at a time. Once you know the correct delay setting for your 96 inputs > your are good to go. Or if no CPU, then a small state machine can also do the job (either sweeping an IDELAY, or in my case the variable phase-shift of a DCM). Cheers, Martin -- martin.j.thompson@trw.com TRW Conekt - Consultancy in Engineering, Knowledge and Technology http://www.conekt.co.uk/capabilities/39-electronic-hardware
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