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
"maxascent" <maxascent@yahoo.co.uk> wrote in message news:4a6dna5Wvce536PZRVn_vA@giganews.com... >I understand what you are saying but is there any industry standard values > that are used. If I were to use these then I can adjust my track size to > get the impedance I need. > Not really, it's up to you to work out the details but they're not terribly difficult to work out then you'll find that in many cases you'll carry over what you did to your next design since it worked so good for you last time. Some of the constraints you'll have are: 1. Overall board thickness. If you have any through hole components (connectors now a days can be about it but don't overlook it or you'll find some part where the leads won't go all the way through and won't get properly soldered). .062, .093 and .125" are some common thicknesses that are driven by the lead length of 'typical' industry parts. 2. Available dielectric materials to use and their thicknesses. Unless you're doing something exotic the material is likely FR4. Check with PCB suppliers for some common thicknesses that they have and their line thickness/spacing constraints. 3. Balanced stackup. Whether you work your way from top to bottom or bottom to top the layers that are power/ground planes need to be symmetrical. (i.e. Top, Plane, Plane, Bottom is the simple case for a 4 layer board). As you work your way in, the thicknesses of the layers need to be symmetric as well. 4. If every layer needs to have controlled impedance then adjacent to each and every signal layer must be a power/ground plane layer. Some examples: 10 layers would be (Top, Plane, Sig, Sig, Plane, Plane, Sig, Sig, Plane, Bottom). 12 layers would be (Top, Plane, Sig, Sig, Plane, Sig, Sig, Plane, Sig, Sig, Plane, Bottom). You'll find that you'll have some difficulty working out an 8 layer arrangement so if it has to be 8 you'll need to make some tradeoffs. 5. Minimum required line and trace widths that you need to actually route the board. Except for power or other high current nets you'll likely be better off making everything the same line width and be done with it (but again, different applications have their exceptions). 6. Impedance control. For digital applications 'many' times you don't so much care what the actual impedance is just that it doesn't vary from layer to layer since odds are you won't be able to route everything on one layer. If that's the situation then you may want to work out a target impedance to shoot for and a layer to layer difference that must be met. As an example, maybe you spec that you want the impedance of each signal layer to be 55+/- 5 ohms. That allows the supplier a relatively wide window to shoot for. But you also want to constrain them so that you don't have Sig1 = 50 ohms, Sig2 = 60 ohms so you need to have an additional spec that says what the largest layer to layer impedance differential you're willing to tolerate will be (2 ohms maybe). The supplier really won't have much trouble meeting this spec since it will likely require them to use the same material and thickness for most of the layers. What will make it difficult is the actual impedance of a layer is important and you can't trade off either overall board thickness or trace width. Working out the math to figure out a rough cut at the impedance and stackup ahead of time will help, if not work with the supplier and talk through what your requirements are and they can pop out a stackup for you in nothing flat since that's they're business. The PCB supplier is generally keenly interested in nailing #1, 2 and 3 to minimize their cost and come up with something that they can fabricate economically so you can expect them to help you get those right. #4, 5 and 6 though generally don't impact their costs directly they really are constraints that they need to be able to meet so you need to be the one driving them to make sure that the stackup meets your product requirements in those areas. KJArticle: 100626
"Joseph Samson" <user@example.net> wrote in message news:TJy%f.1526$Lm5.279@newssvr12.news.prodigy.com... > > I have a webcase open on this issue right now. I want to use PLB_TEMAC > with RGMII, but that combination is currently not supported. I will > update the group when I get an answer. > I have a webcase open as well :) The answer I got so far reads: "The developers are currently working on this matter. Both the hard_temac and the plb_temac cores must have RGMII support included before the interface can be used. There is no set timeline on when this feature will be available. At the earliest however it will be EDK 8.2.02i. This will be towards the end of this year. In the meantime I cannot offer you a workaround to this matter." However, I wonder what can prevent me from instantiating the core in the top level design and connecting to the PLB bus through a custom IP interface? Or connecting it in the way shown in the XAPP807... I have designed a board with RGMII in mind and now it would be very hard to redesign it for GMII... /MikhailArticle: 100627
MM wrote: > "Joseph Samson" <user@example.net> wrote in message > news:TJy%f.1526$Lm5.279@newssvr12.news.prodigy.com... > >>I have a webcase open on this issue right now. > > I have a webcase open as well :) The answer I got so far reads: > > "The developers are currently working on this matter. Both the hard_temac > and the plb_temac cores must have RGMII support included before the > interface can be used. > There is no set timeline on when this feature will be available. At the > earliest however it will be EDK 8.2.02i. This will be towards the end of > this year. > In the meantime I cannot offer you a workaround to this matter." I just got off the phone with my webcase CAE. He says that the next version of PLB_TEMAC (v3) will be released with 8.1 SP2, which was actually supposed to be today. It has RGMII and other features. --- Joe Samson Pixel VelocityArticle: 100628
"Joseph Samson" <user@example.net> wrote in message news:Uzz%f.58788$F_3.20549@newssvr29.news.prodigy.net... > > I just got off the phone with my webcase CAE. He says that the next > version of PLB_TEMAC (v3) will be released with 8.1 SP2, which was > actually supposed to be today. It has RGMII and other features. Great news! Thanks. /MikhailArticle: 100629
I just got my starter kit delivered as well. Whew. A day before the Avnet Speedway seminar in town, too.Article: 100630
Hi, Does anyone have an idea if there is a free ARM emulator out there. We have GHS in house...but the s'ware guys don't have an extra license for me...huffffff Anyways, I am designing a cpld which is memory mapped with a PXA 255 and I need to prove out memory map architecture....I know I can simulate but I derive more pleasure by checking chip selects for peripherals on the scope....delight!!.. Anyways, and help/input will be appreciated. Thanks MORPHEUSArticle: 100631
Hi all, Am working on ML310 board, and EDK. I get similar problem like Xilinx Answer database 18265, 21296, but not quite. The exact problem is in the subject and this is what I do, to land in the problem. A. I create a project in EDK7.1 for ML310 board 1.I initialize the bootloop for PPC405_0 (mark to initialize BRAM ), and unmark the BRAM in the project TestApp. 2.Generate Lib, Bsp , build project/userapplication, Generate Bitstream and update bitstream 3. When doing step 2 Software settings are : PPC405_0:MVL linux and it has several peripherals connected to it PPC405_1: stand alone 4.when I open XMD before downloading the bootloop(download.bit, created after "update bitstream" command), it recognizes the ppc target.id=0 5.when i download the bootloop(download.bit), and open XMD it doesnot recognize the ppc Target.saying it has Invalid Processor Version No 0x00000000 Can anyone tell me where i am going wrong? I appreciate all the help. With warm regards, Chakra.Article: 100632
lecroy7200, While it is true that we don't specify a LVDS clock that high in frequency, the IO is perfectly capable of going way past 1.2GHz, so it becomes a question of duty cycle distortion on the clock resources inside. It won't be 45/55% like the spec sheet says, but it will still have a perfectly good pulse there. Obviously National is using this. Since they are using it, that makes Xilinx kind of responsible for some support of this application. What that means is that if you use it the way they did, we will support it (wiring, t-lines, terminations, paths used, speed grade, etc.). Similar to the PCI interface, the basic PCI operates outside of our specifications, but we support it, as we have tested our PCI core in our parts, and found it to work just fine. This is known as support of "application outside of specification." If you are curious, there are very few of these. PCI is the largest. After that, I would guess you fall into something like the National application (very small compared with the overall usage). Austin lecroy7200@chek.com wrote: > I was watching Avnets' sponcered video with Robert Pease and Howard > Johnson where National had a board with a ADC08D1500 dual ADC tied > directly into a Virtex 4. The videos, datasheets, etc may be found at: > > http://www.national.com/xilinx/ > > The LVDS clock coming from the ADC is 750MHz. They route this clock > directly to the Virtex 4. When I look at the specs. for the Virtex 4, > this would seem to be way outside of what it is rated for. > > My question is this, did National do some neat trick to make this work, > or did they just exceed the specs of the device knowing it was not a > production unit and did not really worry about it? Or did I miss > something? > > Also, if anyone purchased the eval. board, I would be interested in > hearing if U5 was populated with the LMH6550 or some other part. > > Thanks >Article: 100633
> > The LVDS clock coming from the ADC is 750MHz. They route this clock > directly to the Virtex 4. When I look at the specs. for the Virtex 4, > this would seem to be way outside of what it is rated for. > > My question is this, did National do some neat trick to make this work, > or did they just exceed the specs of the device knowing it was not a > production unit and did not really worry about it? Or did I miss > something? > IIRC: 8 bits @ 1.5 Ghz sample clock => 16 bits @ 375 MHz DDR clk to FPGA The National A/D's have an on-board 1:2 demux, so at a clock rate of 1.5 Ghz, the 8 bit samples come out 16 bits wide with the DCLK output clock selectable as either SDR (750 Mhz) or DDR (375 MHz). No out of spec handwaving dispensations are required from San Jose. Brian p.s. Re your other post, the new high-end LatticeSC parts are claiming 2Gbps parallel LVDS I/O, with some interesting split-to-VTT and center-tap-cap on-chip termination modes.Article: 100634
morpheus wrote: > Hi, > Does anyone have an idea if there is a free ARM emulator out there. We > have GHS in house...but the s'ware guys don't have an extra license for > me...huffffff > Anyways, I am designing a cpld which is memory mapped with a PXA 255 > and I need to prove out memory map architecture....I know I can > simulate but I derive more pleasure by checking chip selects for > peripherals on the scope....delight!!.. > Anyways, and help/input will be appreciated. > Thanks > MORPHEUS I have a book by Arnold Berger "Hardware and Software Organization" which is supposed to have an instruction set simulator for the ARMV3 ISBN 0-7506-7886-0 Good luck, DaveArticle: 100635
Since the max serial-slave configuration rate on things like Spartan3 chips is, what, 20 MHz or something, you might consider slowing down the CCLK input path, and/or adding some serious hysteresis on future parts. On a pcb, CCLK is often a shared SPI clock, with lots of loads and stubs and vias and such, so may not be as pristine as a system clock. CCLK seems to be every bit as touchy as main clock pins, and it really needn't be. JohnArticle: 100636
John Larkin wrote: > > Since the max serial-slave configuration rate on things like Spartan3 > chips is, what, 20 MHz or something, you might consider slowing down > the CCLK input path, and/or adding some serious hysteresis on future > parts. On a pcb, CCLK is often a shared SPI clock, with lots of loads > and stubs and vias and such, so may not be as pristine as a system > clock. CCLK seems to be every bit as touchy as main clock pins, and it > really needn't be. > > John John, Are your suggestions for the CCLK generated by the Xilinx device or the CCLK received by the Xilinx device? I think the max speed is up to 66 MHz these days in the Spartan3E. It may not be LVDS rates but it's not 4000 series logic, either. - John_HArticle: 100637
Hi, I'll not use PROG_B with my Spartan3, should I just pull-it up with 10k? Is it true that I can alway access the FPGA through the JTAG port even if the M0-M2 are hardware-set for slave/master serial? Thanks, MarcoArticle: 100638
"Marco" <marco@marylon.com> schrieb im Newsbeitrag news:1144999372.724233.229220@u72g2000cwu.googlegroups.com... > Hi, > I'll not use PROG_B with my Spartan3, should I just pull-it up with > 10k? > Is it true that I can alway access the FPGA through the JTAG port even > if the M0-M2 are hardware-set for slave/master serial? > Thanks, Marco > yes m0,m1,m2 are dont cared for JTAG but PROG_B *must* be high or jtag config will fail, there I think it supposed to be internal pullup on prog_b but at least with xilinx virtex I have seen that external pullup is also required, so better have it in place anttiArticle: 100639
John Larkin wrote: > On a pcb, CCLK is often a shared SPI clock, with lots of loads > and stubs and vias and such, so may not be as pristine as a system > clock. CCLK seems to be every bit as touchy as main clock pins, and it > really needn't be. > What it's really saying is that when designing a PCB, CCLK should be treated with as much care and respect as any other clock signal so you won't have lots of loads, stubs and vias and such. KJArticle: 100640
Thanks all for the advice. Regarding my stack I was planning to do this :- Top Gnd Power Mid1 Mid2 Power Gnd Bottom Does the above seem sensible or would it be better to use 10 layers? Cheers JonArticle: 100641
maxascent schrieb: > Thanks all for the advice. Regarding my stack I was planning to do this :- > > Top > Gnd > Power > Mid1 > Mid2 > Power > Gnd > Bottom As you are likely to have more than two power supply voltages you should substitute one of the ground planes by another power plane. For impedance control it does not matter what the electrical potential of the plane is. Kolja SulimmaArticle: 100642
> If anyone knows of any 2C70 boards, do let us know. You're lucky ! The Lead-Free / RoHS compliant version of the Cyclone II based DSP board will be with the EP2C70 ! Kind regards, Karl.Article: 100643
maxascent wrote:
> Thanks all for the advice. Regarding my stack I was planning to do this :-
>
> Top
> Gnd
> Power
> Mid1
> Mid2
> Power
> Gnd
> Bottom
>
> Does the above seem sensible or would it be better to use 10 layers?
>
> Cheers
>
> Jon
Personally, I like your stackup. Having chopped-up power planes is fine
as long as certain precautions are taken:
Make sure the power islands aren't fed over tiny tracks
Place adequate decoupling on the power islands
Have adequate decoupling caps near plane splits
(to provide a decent return current path)
Every time a signal changes layers, there's a chance to introduce
crosstalk through common return paths. A sprinkling of decoupling caps
and/or ground/ground connections helps reduce the current loops that can
make EMI/EMC nasty in addition to the crosstalk issues.
Article: 100644On 14 Apr 2006 03:03:17 -0700, "KJ" <Kevin.Jennings@Unisys.com> wrote: >John Larkin wrote: >> On a pcb, CCLK is often a shared SPI clock, with lots of loads >> and stubs and vias and such, so may not be as pristine as a system >> clock. CCLK seems to be every bit as touchy as main clock pins, and it >> really needn't be. >> > >What it's really saying is that when designing a PCB, CCLK should be >treated with as much care and respect as any other clock signal so you >won't have lots of loads, stubs and vias and such. > And what I'm saying is that treating it as such shouldn't be necessary. JohnArticle: 100645
On Fri, 14 Apr 2006 05:53:30 GMT, John_H <johnhandwork@mail.com> wrote: >John Larkin wrote: >> >> Since the max serial-slave configuration rate on things like Spartan3 >> chips is, what, 20 MHz or something, you might consider slowing down >> the CCLK input path, and/or adding some serious hysteresis on future >> parts. On a pcb, CCLK is often a shared SPI clock, with lots of loads >> and stubs and vias and such, so may not be as pristine as a system >> clock. CCLK seems to be every bit as touchy as main clock pins, and it >> really needn't be. >> >> John > >John, > >Are your suggestions for the CCLK generated by the Xilinx device or the >CCLK received by the Xilinx device? > In serial-slave mode, the FPGA receives CCLK. >I think the max speed is up to 66 MHz these days in the Spartan3E. It >may not be LVDS rates but it's not 4000 series logic, either. Right. Improving the noise immunity of the CCLK receiver would have exactly one practical result: more FPGAs would configure. JohnArticle: 100646
Hi all,
i have a problem, the code as below, the all condition
signals(excludes rst_n)
is generated by posedge clk_in. I have run in simulation the counter
"count" is normal.
the new "count" is generated by posedge clk_in. but when I use FPGA
emulation
and observe the new "count" in sometime is generated by negedge
clk_in. what happen
to this situation? it cannot same as simulation result.
I am using Quartus 5.0 for compiling and fitting, the timing report is
OK.
Hope someone could give me some suggestion to this situation, thanks a
lot.
############################################################
always @(negedge rst_n or posedge clk_in)
if ( !rst_n ) begin
count <=4'b0;
end else begin
if ( inst_en ) begin
count <=4'b0;
end else begin
if ( op_state ) begin
if( count==`OP_CNT ) count <=4'b0;
else if ( !c_sel ) count <= count + 1;
end else if (byte_state) begin
if( count==`BYTE_CNT ) count <=4'b0;
else if ( !c_sel ) count <= count + 1;
end else if ( addr_state ) begin
if( count==`ADDR_CNT ) count <=4'b0;
else if ( !c_sel ) count <= count + 1;
end else if ( data_state ) begin
if ( inst==`AA_wr || inst==op_program ) begin
if( count==`BYTE_CNT ) count <=4'b0;
else if ( !c_sel && hold_wr ) count <= count + 1;
end else begin
if( count==`BYTE_CNT ) count <=4'b0;
else if ( !c_sel && hold_rd ) count <= count + 1;
end
end
end
end
##############################################################
Article: 100647(Google didn't allow me to reply to the original thread, so I copied the previous message in myself) On Mon, Jan 9 2006 6:27 pm, Gilles Georges wrote : > I just tried the cable with same board on a Win XP computer and it > works. I previously downgrade to cpld firmware V4 (taken in a ISE 6.3 > linux install) => not working under linux but working under windows. > Then i upgrade to version 6 and still working under windows. > > Going back to my Linux workstation nothing works. > > There is a strange thing with Impact, the "CPLD version" differs with > the "CPLD file version" while the two match on Windows. > > Connecting to cable (Usb Port - USB22). > Checking cable driver. > File version of /local/xilinx/bin/lin/xusbdfwu.hex = 1018(dec), 03FA. > File version of /etc/hotplug/usb/xusbdfwu.fw/xusbdfwu.hex = 1018(dec), 03FA. > Max current requested during enumeration is 150 mA. > Cable Type = 3, Revision = 0. > Setting cable speed to 6 MHz. > Cable connection established. > Firmware version = 1018. > CPLD file version = 0006h. > CPLD version = 0021h. > > Any idea. I've got the same problem here: the USB cable works fine with windows, but using linux, the CPLD version is mis-read, and the only thing happening is the firmware being updated. (which takes almost an hour, hilarious!). I'm using ISE 8 instead of 6, but the symptoms are the same. I just contacted Gilles in private to see if he found any solution to this issue yet. His workaround is the same as mine: use a windows machine for programming with the USB platform cable. I'm sure that's not what xilinx had in mind, when the published the Linux drivers for this cable. Does anybody have this cable working yet, running a 2.6 linux kernel ?Article: 100648
1 GND plane in an 8-layer stack? I was under the belief that yes, a power plane can serve as a return path for a signal, but it's not preferred or equal over a GND plane. I would think partitioning the power planes is a safer bet than cutting another GND layer.Article: 100649
I have looked at the data sheet and they say very clearly that the Spartan 3 is held in reset until all three power supplies are fully up. But the range of voltages is very wide, with reset being released when the Vcoo on Bank four is as low as 0.4 volts. I get a lot of grief from the FPGA firmware designers on every little nit and pic that they don't like about the board design. I need to know that this will keep the FPGA in reset and all IOs tristated whether the various power voltages are above or below the internal reset threshold, up to the point of being configured.
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