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
Good Afternoon, I am writing a simple UDP core to send data from a Xilinx S3E to PC via Ethernet sending UDP packets, and have a query relating to endianness and the PHY: LAN83c185: http://www.smsc.com/media/Downloads_Public/Data_Sheets/83c185.pdf My understanding is that the byte order is Big Endian, thus the most significant byte first: Thus an IP would be sent: C0 then A8 then 00 then 01 for the IP 192.168.0.1 I also read that each byte must be sent with the LEAST SIGNIFICANT NIBBLE first: Thus in terms of nibbles, that IP would be: 0 then C then 8 then A then 0then 0 then 1 then 0 My confusion comes from the interface to the PHY. It is a 4 bit bus, so I obviously have to send one nibble at a time. I understand this should be the least significant nibble of every byte followed by the more significant nibble. My question is the BIT ORDER of each of the nibbles. I understand that ethernet bitstream is the LEAST SIGNIFICANT BIT of each byte. Basically I am not sure if I should send the nibble for the PHY in its normal format, or if I should bit reverse it: ie: For nibble A, do i send: "1010" to PHY pins 3:0, or do I send "0101" to PHY pins 3:0. I cannot find out whether the PHY handles the bit order of each nibble in the way it handles all the NRZI stuff etc. Sorry for the poor wording, but I find endianness is one of things so hard to explain etc. GintsArticle: 142301
I've never actually used webise so I cant really say. You may be best to just stick with verilog at the moment if you are just doing it as a hobby. To get system verilog functionality you would probably have to spend some money on more expensive tools. Cheers JonArticle: 142302
Hi Brian, > =A0- Set the FPGA mode pins to JTAG mode, not to SPI mode, when > =A0 =A0programming over JTAG using the Impact SPI flash core. --> I can try this, but, sorta defeats having a bootable FPGA. The 500E version works fine without needing to do this. > =A0 ( Otherwise the FPGA SPI boot process can fight with the JTAG port ) --> I think it tries 3 times to load from spi and then gives up. > > =A0- Change the JTAG clock rate used by Impact to one of the slower > speeds, --> Its not a JTAG related issue, but I have tried this for sanity. I set the cable speed to its slowest (750Kbps) - still no go. > =A0 =A0and make sure it can reliably run the JTAG loopback test at that > rate --> Loop backworks fine a 10MHZ for 1M test cycles - all passes ok, so communicating with the device is 100% ok - allways has been. Talking to the FPGA has always been fine - you can download projects and things work great. the only problem is, the FPGA is unable to write to its flash using xilinx precompiled cores, xc3s250e_spi.cor. this spi bridge core is unique to each device and each package. The 500E PQ208 version works beautifully - but the 250E PQ208 version seems to be a bug fest. Is the source available for these? I expect I will have to write my own, or bite the bullet and leave the spartan and go with altera. steveArticle: 142303
I just went to Xilinx's website to log a case with them. Xilinx now screen who they feel is suitable for logging cases, and those who they feel are not - takes a day for them to decide after you request to log a case. I think their patent is about to run out... I feel a change of guard not far off.Article: 142304
On Aug 1, 5:29=A0pm, "BobW" <nimby_GIMME_SOME_S...@roadrunner.com> wrote: > "Nico Coesel" <n...@puntnl.niks> wrote in message > > news:4a749265.358227234@news.planet.nl... > > > > > "BobW" <nimby_GIMME_SOME_S...@roadrunner.com> wrote: > > >>"Nico Coesel" <n...@puntnl.niks> wrote in message > >>news:4a7477d0.351422078@news.planet.nl... > >>> Some food fo thought: > > >>> I'm working on a new design in which I need to bring 64 LVDS (250Mbps > >>> each/ 125MHz fmax) lines into a Spartan3 FPGA. The distance between > >>> the source and the FPGA is less than 2" / 5cm. Ofcourse there is a > >>> solid ground plane underneath the signals (the board will have at > >>> least 4 layers). > > >>> I'm wondering if I can save a lot of pins if I feed the LVDS signals > >>> single ended into the FPGA (terminate the pair close to the FPGA and > >>> leave one end dangling). I could bias the Vref pins on the FPGA to th= e > >>> centre point of the LVDS signal. If I set the input pin type to GTL i= t > >>> should work on paper. The LVDS signal has enough swing to exceed the > >>> minimum signal amplitude. > > >>> Anyone ever tried this? > > >>> -- > > >>The thing that would concern me is how to guarantee that VREF is held a= t > >>the > >>centerpoint (common mode) of the signal swing. If you were only dealing > >>with > > > The datasheet of the source chip specifies that. I more or less assume > > the source chip has the same centerpoint on all outputs. > > >>one pair then you get tricky and extract the common-mode point from tha= t > >>pair - assuming that the signal was always transitioning. Knowing that > > > IMHO you don't need a signal that is always toggling. If you connect a > > resistor to each leg of the pair and a capacitor to ground (resistor > > divider between the two legs) then the voltage across the capacitor > > should be the centre voltage no matter what the LVDS signal looks > > like. > > Ahhh, yes. Silly me. > > I hope this works out for you. I suspect it will if you adapt VREF to the > true centerpoint of one of the signals and if all the driver's common mod= e > points stay fairly close to each other. > > If one of those pairs is a forwarded clock, and if you decide to do the V= REF > adapt technique, then I wouldn't use the clock line for that function. LV= DS > is not intrinsically source terminated (it's high impedance drive [curren= t > source]). So, if you get any type of end reflection it will eventually co= me > back toward that receiver. Data lines are somewhat forgiving. Clock lines > are like women. > > Bob > -- > =3D=3D All google group posts are automatically deleted due to spam =3D= =3D You should consider running both halves of each pair up to the Spartan 3 and terminate with 100 ohms differential near the pin. This gets rid of the reflection issue although you end up with more routing. It also addresses another issue found with most LVDS drivers that I've come across. They are designed to run into a 100 ohm differential load. Very often they won't work properly without the load. What I see is that the signal swing increases significantly without the load, especially at low frequencies. Then the switching delay increases with the increased swing. So if you have a data bit that toggles on random clock edges, the clock to output delay through the LVDS device will be longer after it has sat at the same value for more than one clock period than on edges where it toggled on the previous cycle. This second issue could be handled with the termination resistor near the source, but once you have the extra parts and routing, it seems reasonable to put the resistor where it gives the best signal integrity. Regards, GaborArticle: 142305
Have you verified the SPI chip against the file to identify whether it's a programming or FPGA load issue. I just had a nightmare problem with a Lattice part where the tools would sometimes generate a file that would run in the device via JTAG but not load from SPI PROM - it was very design-content and in some cases device type dependent. The Lattice tools look VERY similar to ISE so I wonder if there may be some connection...Article: 142306
Hi, I have a Spartan 3E (xc3s1200e-5) in fg320. Maybe something is wrong in the .ucf file because the placer says WARNING:Route - CLK Net:extref_clk_pin_IBUFG is being routed on general routing resources. Please consider using a dedicated clocking routing resource. For more information on clock routing resources, see the target architecture's user guide. And what I have in the .ucf file is NET extref_clk_pin LOC = B10; ## pinheader J4, pin 10, GCLK_L12_P NET extref_clk_pin IOSTANDARD = LVCMOS33; NET extref_clk_pin TNM_NET = extref_clk_pin; TIMESPEC TS_extref_clk_pin = PERIOD extref_clk_pin 200000 ps; The ds312.pdf Spartan 3E FPGA Family Datasheet http://www.xilinx.com/support/documentation/data_sheets/ds312.pdf says on page 204 that the ball B10 is _supposed_ to be "GCLK" and pin name on 1200e is IO_L12P_0/GCLK6. So why does Route say it routes over some non-clock route? Perhaps there is something missing in the UCF? - JanArticle: 142307
JanW wrote: > > So why does Route say it routes over some non-clock route? > Jan, Have you connected this net to anything in the FPGA fabric that isn't a dedicated clock input? HTH., Syms.Article: 142308
It could be the way that you have defined your clk in the hdl. Check that it is connected to a clock input buffer. JonArticle: 142309
On Aug 3, 1:57=A0pm, JanW <no_s...@thanks.net> wrote: > Hi, > > I have a Spartan 3E (xc3s1200e-5) in fg320. Maybe something is wrong > in the .ucf file because the placer says > > WARNING:Route - CLK Net:extref_clk_pin_IBUFG is being routed on > general routing resources. Please consider using a dedicated > clocking routing resource. For more information on clock routing > resources, see the target architecture's user guide. > > And what I have in the .ucf file is > > NET extref_clk_pin LOC =3D B10; ## pinheader J4, pin 10, GCLK_L12_P > NET extref_clk_pin IOSTANDARD =3D LVCMOS33; > NET extref_clk_pin TNM_NET =3D extref_clk_pin; > TIMESPEC TS_extref_clk_pin =3D PERIOD extref_clk_pin 200000 ps; > > The ds312.pdf Spartan 3E FPGA Family Datasheet > > http://www.xilinx.com/support/documentation/data_sheets/ds312.pdf > > says on page 204 that the ball B10 is _supposed_ to be "GCLK" and > pin name on 1200e is IO_L12P_0/GCLK6. > > So why does Route say it routes over some non-clock route? > > Perhaps there is something missing in the UCF? > > =A0 - Jan It's not the UCF file. The fact that the buffered input is labeled extref_clk_pin_IBUFG, with a "G" at the end shows that the pin is indeed a global clock input and the appropriate input buffer is in use. If you don't run this net to either a BUFG or a DCM in the chip, however you won't get the global routing resources you expect. Normally ISE will insert the correct buffers into the design unless you change some default settings or specifically indicate the clock buffer type in your source. You can open the design in FPGA editor to see what happened to this net. Regards, GaborArticle: 142310
> > The trick here is is that I'm not sure how to implement and actually > > use IPs with a synthesized CPU, which is what I must look into I > > guess. Essentially, I understand the project build process until one > > gets to the Xilinx SDK. The way I understand it, the SDK allows one to > > apply C and C++ code to an FPGA project. > > Yes, SDK allows to load the C/C++ code to microblaze that is > configured in FPGA. Now, this microblaze (or any other soft-core > processor) is on of the hardwares that can be in FPGA. You can > describe your own peripherals/ hardwares using languages like VHDL/ > Verilog (or other..) or use IPs designed by others. These can also be > placed within the same FPGA. > Now, I think which is your question: How to integrate both hardware > and software. > Use (assuming you want to use microblaze) Xilinx's EDK or XPS . You > can use "The Create and Import Peripheral Wizard" in XPS to add your > IPs into the system and make it talk with the microblaze. > > > Can anyone point me in the right direction for use of the SDK to > > implement IPs such as memory interfaces and ethernet controllers (i.e. > > a good reference document, a working example of something doing one of > > these things, etc.) > > You can get some, just google with keywords like: custom peripheral > edk; create and import peripheral wizard; ... Thank you kindly. I think I'm headed in the right direction now.Article: 142311
gabor kirjoitti:
> It's not the UCF file. The fact that the buffered input is labeled
> extref_clk_pin_IBUFG, with a "G" at the end shows that the pin is
> indeed a global clock input and the appropriate input buffer is in
> use.
Ups, good catch.
> If you don't run this net to either a BUFG or a DCM in the
> chip, however you won't get the global routing resources you
> expect.
It should go directly to a DCM.
Generated that dcm in XPS 10.1 with the IP Catalog -> DCM (SP) -> ip
setup wizard. And the generated wrapper contains C_CLKIN_BUF => TRUE
and the system.vhdl has
extref_clk_s <= extref_clk_pin;
DCM_SP_INST : dcm_sp_inst_wrapper
port map (
CLKIN => extref_clk_s,
CLKFB => clk_ext_clk0,
CLK0 => clk_ext_clk0,
CLKFX => clk_ext,
LOCKED => outDCMlocked_s,
...
);
> Normally ISE will insert the correct buffers into the
> design unless you change some default settings or specifically
> indicate the clock buffer type in your source.
Ok. I did change the C_CLKIN_BUF to true i think. Will retry.
> You can open
> the design in FPGA editor to see what happened to this net.
True, once this tedious "make clean; make" of XPS finishes. Then I
try to get the hang of horrific floor planner / fpga editor ;)
- Jan
Article: 142312Steve wrote: > > > - Set the FPGA mode pins to JTAG mode, not to SPI mode, when > > programming over JTAG using the Impact SPI flash core. > > I can try this, but, > If you haven't tried this mode change yet, I'd suggest that you place it at the top of the "things to do" list. The recommendation to select JTAG mode during indirect SPI programming can be found in the newer Xilinx SPI programming application notes [Ref 1]. > > sorta defeats having a bootable FPGA. > Set it to JTAG when you connect the JTAG cable to program the SPI flash with Impact, set it back when you are done... Adding a mode select jumper block hardly reduces the functionality of a board, particularly when this mode jumper is often needed to use the JTAG port without experiencing the sort of problems that you are seeing. If you want the mode selection to be automatic, the 2mm 14 pin JTAG header pinout can be used to provide a JTAG cable detect [Ref 2]. > > The 500E version works fine without needing to do this. > These PROM/JTAG boot conflicts can vary from part to part, and between mask steppings of the same device. The earlier S3E steppings had similar BPI vs. JTAG mode conflicts, see [Ref 3] for some examples > > Is the source available for these? I expect I will have to > write my own, or bite the bullet and leave the spartan and > go with altera. > The Impact SPI core source is _not_ available [Ref 4]. There is an example of an S3E SPI flash programmer in the S3E starter kit examples [Ref 5], but I've never used it. I think there is also some sort of FlashWriter app in the EDK, but I have no experience with that one either. Brian ------------- [Ref 1] S3 SPI application notes suggesting JTAG mode jumper XAPP974 (v1.1.3) Indirect Programming of SPI Serial Flash PROMs with Spartan-3A FPGAs figure 2, note 5, page 4: " " The jumper on the M[2] pin is an enhancement for prototyping " and debugging, to allow changing from SPI Mode M[2:0] =3D 001 " to JTAG mode M[2:0] =3D 101. " Table 2, page 5: " " For JTAG mode for programming SPI Flash PROMS, " set M[2:0] =3D 101 " http://www.xilinx.com/support/documentation/application_notes/xapp974.pdf ------------- [Ref 2] Automatic JTAG Cable Detection The 14 pin, 2mm Xilinx JTAG header pinout allows for the use of pin 13 as a cable detect. On the newer USB II cables, pin 13 is an open drain output called 'PGND' that is grounded when the cable is active: DS593 v1.2, page 15 http://www.xilinx.com/support/documentation/data_sheets/ds593.pdf On the older Parallel IV and original Platform Cable USB pin 13 is a ground pin: DS300 v3.2 figure 17, page 9 http://www.xilinx.com/support/documentation/data_sheets/ds300.pdf So tie pin 13 to a pullup on board, and use the resulting logic level to select the configuration mode, either directly or through some logic or jumpers on the board. For S3E, M2 is the only pin that changes between serial SPI (M2=3D1) and JTAG (M2=3D0) modes, so the pin 13 pullup could simply be tied to the M2 line. ------------- [Ref 3] S3E JTAG/PROM conficts & steppings AR #22142 - Spartan-3E Configuration - I cannot program a Spartan-3E FPGA via JTAG if the FPGA is in BPI Mode http://www.xilinx.com/support/answers/22142.htm 2008 post listing other similar bugs: http://groups.google.com/group/comp.arch.fpga/msg/b06ca9faf716c347 ------------- [Ref 4] Unavailability of Impact SPI core source XAPP974 (v1.1.3) third paragraph, page 17 " " The core is for iMPACT runtime use only =97 the source code " is not available for designs. " http://www.xilinx.com/support/documentation/application_notes/xapp974.pdf ------------- [Ref 5] S3E Picoblaze based SPI flash programmer http://www.xilinx.com/products/boards/s3estarter/files/s3esk_serial_flash.= pdf http://www.xilinx.com/products/boards/s3estarter/files/s3esk_serial_flash.= zipArticle: 142313
Hi Brian, Thanks for the solid response. Ill try the things you suggest to see if that resolves the problem, but I do have a few initial comments on some of these suggestions; > =A0The recommendation to select JTAG mode during indirect > SPI programming can be found in the newer Xilinx SPI > programming application notes [Ref 1]. --> Thats somewhat dissapointing, as i have an existing design in production based on their "Designs can migrate between the XC3S250E and XC3S500E without further consideration." statement found on page 189 of their DS312 datasheet (who knows if its current, or true - does it matter?) > > > > sorta defeats having a bootable FPGA. > > =A0Set it to JTAG when you connect the JTAG cable to program > the SPI flash with Impact, set it back when you are done... Hard to do with 0402 components, but ill bolt it on an see what happends. > > =A0Adding a mode select jumper block hardly reduces the > functionality of a board, particularly when this mode > jumper is often needed to use the JTAG port without > experiencing the sort of problems that you are seeing. I think it does. For upgrades, plugging up to the JTAG port and downloading is a lot easier than including instructions for jumpers, especially when the product is closed to the world. DS312, it also states JTAG always gets priority over other methods, well, up until now. A jumper is a bug fix for this device, for xilinx. Again, may have to do it, but if I have to spin the board again, its just as easy for me to put another vendor device on there. > > =A0If you want the mode selection to be automatic, the 2mm > 14 pin JTAG header pinout can be used to provide a JTAG > cable detect [Ref 2]. --> I dont wish to be tied to just xilinx programmers. Native JTAG interface is what we are using. JTAG has too many pins as it is. > > > > > The 500E version works fine without needing to do this. > > =A0These PROM/JTAG boot conflicts can vary from part to part, > and between mask steppings of the same device. Ive noticed with xilinx, the same part varies as well - going with an xilinx ES part is suicide. However, since it was spelt out in DS312 its ok to swap a 250E with a 500E with only code changes, I sorta thought that meant I could swap between a 250E and a 500E with only code changes. steveArticle: 142314
I want to know how much is the program memory space for Microblaze processor in Spartan 3A device or any similar device. and where is this program memory actually in FPGA (considering there is no external memory attached). (i think Microblaze processor uses on chip Block RAM for the processor memory it was about 64KB maximum for Spartan 3 as in Xilinx Platfrom Studio Configuration page for Microblaze) I couldnot find related data on website, if you know where is this detail on the web can you also give the Link. Best Regards Nauman MirArticle: 142315
On Aug 4, 7:29=A0am, Nauman Mir <m...@hotmail.com> wrote: > I want to know how much is the program memory space for Microblaze > processor in Spartan 3A device or any similar device. > > and where is this program memory actually in FPGA (considering there > is no external memory attached). > (i think Microblaze processor uses on chip Block RAM for the processor > memory it was about 64KB maximum for Spartan 3 as in Xilinx Platfrom > Studio Configuration page for Microblaze) > > I couldnot find related data on website, if you know where is this > detail on the web can you also give the Link. > > Best Regards > > Nauman Mir you can configure most of the BRAMs to be used MB on chip look at the datasheet and calculate :) you can only uses sizes supported by EDK, but you can use multiply blocks like 32KB + 8KB block would give 40KB total AnttiArticle: 142316
Hi,
I have been asked to read 8 bits at a time from a hexadecimal input
file as an input to testbench. I found a construct $readmemh in verilog but
it says that the arrangement of file has to be in this order
23
45
67
whereas the file structure that i have is 23 45 67 ...
Can somebody help me with this file reading using I/O?
Article: 142317On 4 Aug, 09:22, "DAJ" <donia.j...@gmail.com> wrote: > Hi, > =A0 =A0I have been asked to read 8 bits at a time from a hexadecimal inpu= t > file as an input to testbench. I found a construct $readmemh in verilog b= ut > it says that the arrangement of file has to be in this order > 23 > 45 > 67 > whereas the file structure that i have is 23 45 67 ... > Can somebody help me with this file reading using I/O? If the data isn't in the format you need, write a small program that converts it into a format suitable for $readmemh. Alteratively, if your simulator supports Verilog2001, see here: http://www.asic-world.com/verilog/verilog2k3.html for how to use $fscanf. Cheers, JonArticle: 142318
On Aug 4, 4:22=A0am, "DAJ" <donia.j...@gmail.com> wrote: > Hi, > =A0 =A0I have been asked to read 8 bits at a time from a hexadecimal inpu= t > file as an input to testbench. I found a construct $readmemh in verilog b= ut > it says that the arrangement of file has to be in this order > 23 > 45 > 67 > whereas the file structure that i have is 23 45 67 ... > Can somebody help me with this file reading using I/O? Separate lines or a space between the characters (as you have indicated) will both work.Article: 142319
On Aug 4, 9:15=A0am, mike <gosenator...@hotmail.com> wrote: > On Aug 4, 4:22=A0am, "DAJ" <donia.j...@gmail.com> wrote: > > > Hi, > > =A0 =A0I have been asked to read 8 bits at a time from a hexadecimal in= put > > file as an input to testbench. I found a construct $readmemh in verilog= but > > it says that the arrangement of file has to be in this order > > 23 > > 45 > > 67 > > whereas the file structure that i have is 23 45 67 ... > > Can somebody help me with this file reading using I/O? > > Separate lines or a space between the characters (as you have > indicated) will both work. $readmemh requires "whitespace" between the values per the Language Reference Manual. Modelsim should have no problem with the data as you have it. HOWEVER, XST, while allowing $readmemh for initialization of memory for synthesis, requires the entries to be one per line. If you are using the ISE simulator rather than ModelSim, you might find the same "feature" holds true. I have not tried ISIM, so you should give it a try before jumping through the hoops required to reformat your file. By the way, the Verilog LRM also allows verilog comments and address lines in the data files for $readmemh. XST does not support these constructs, either. Regards, GaborArticle: 142320
Hello, Is it possible that even though I use AES encrypted bitstream, another trojan/bad bitstream that mimiked my design could be loaded into FPGA? Regards, RajArticle: 142321
> Is it possible that even though I use AES encrypted bitstream, another > trojan/bad bitstream that mimiked my design could be loaded into FPGA? If your design can be mimiked AES encryption seems not necessary.Article: 142322
Raj, With Xilinx FPGA encryption, decryption solutions since Virtex 2, only one bitstream is allowed to be entered in secure mode. That bistream's key must be the one in the battery backed key memory, or the device will not program. Some parts allow subsequent partial reconfiguration, again they must use the same key (encrypted), so the attacker would have to know your key in order to do this. If they know your key, well, you are not secure, are you? At any time, you may program the device again with another bitstream, but that erases the previous (decrypted) bitstream. While programmed with a encrypted bitstream, JTAG readback is disabled, so you can not read the device out. But, if you place logic in your encrypted design to perform the internal configuration readback, and readback and output the values on a pin (for example), then you have now created your own "back - door." We do not protect against doing something this stupid, but we do protect the bitstream from all other attacks if you follow a few simple rules (like: do not build a back door into your design). SInce Virtex 2, we have issued challenges to university students and researchers to test our security. In addition to being the only approved FPGA by the NSA for the crypto-modernization program, we have had no method of attack succeed to date,Article: 142323
On Aug 4, 10:54=A0am, austin <aus...@xilinx.com> wrote: > With Xilinx FPGA encryption, decryption solutions since Virtex 2, only > one bitstream is allowed to be entered in secure mode. > > That bistream's key must be the one in the battery backed key memory, > or the device will not program. so if you remove the battery, can you program anything you want into the fpga? (this is what i thought the op was asking)Article: 142324
On Aug 4, 2:19=A0pm, "a...@nishioka.com" <a...@nishioka.com> wrote: > On Aug 4, 10:54=A0am, austin <aus...@xilinx.com> wrote: > > > With Xilinx FPGA encryption, decryption solutions since Virtex 2, only > > one bitstream is allowed to be entered in secure mode. > > > That bistream's key must be the one in the battery backed key memory, > > or the device will not program. > > so if you remove the battery, can you program anything you want into > the fpga? > (this is what i thought the op was asking) Yes, it is related to what i ask. this is one method removing the battery, if that is not possible, shorting the battery terminals until it is drained.
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