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 Apr 6, 11:53=A0am, Ed McGettigan <ed.mcgetti...@xilinx.com> wrote:
> On Apr 5, 3:53=A0pm, James <jmos1...@gmail.com> wrote:
>
>
>
>
>
>
>
>
>
> > I want to use create_generated_clock to generate a clock that is half
> > the frequency of the source clock and also phase shifted by 90
> > degrees. =A0I'm using Xilinx's new SDC support which does not have the =
-
> > phase option that Altera includes. =A0I cannot find ANY worthwhile
> > documentation on how to specify my edge list for the edge_shift
> > option. =A0Can someone please help me out? =A0I currently have the
> > following which may or may not be correct:
>
> > create_generated_clock \
> > =A0 =A0 -name my_new_clock \
> > =A0 =A0 -divide_by 2 \
> > =A0 =A0 -edges { 1 3 5 } \ =A0 <-- also divides the clock by 2, so the
> > divide_by option is not really necessary
> > =A0 =A0 -edge_shift { 1 1 1 } \ =A0<-- not really sure about this part =
...
> > wondering if this is correct
> > =A0 =A0 -source [get_pins source_clock] \
> > =A0 =A0 =A0 =A0 =A0 =A0 [get_nets {new_clock}]
>
> > I know most of the above constraint is correct, but I don't know if I
> > have specified the edge_shift correctly. =A0Remember, I want to divide
> > the source_clock by 2 and then shift it by 90 degrees.
>
> > The best documentation I can find with Google is on Altera's site.http:=
//www.altera.com/support/software/timequest/clock/tq-generate-cl...
> > The site provides the following example:
>
> > # Creates a divide-by-2 clock independent of the master clock's duty
> > cycle now 50%)
> > create_generated_clock -source [get_ports clk] -edges { 1 1 5 } -
> > edge_shift =A00 5 0 } [get_registers clkdivB|clkreg]
>
> > The above example corresponds to Figure 2 on the linked web page. =A0I
> > don't entirely understand this example or how the edge_shift is {0 5
> > 0}. =A0It would be great if someone could explain that as well.
>
> > Thanks for any help.
> > James
>
> The SDC constraints can be used to describe timing relationships (as
> well as other design constraints such as placement locations) for use
> by the timing analyzer. =A0They cannot be used to drive the tools to
> create a physical clock condition as it appears you are attempting.
>
> You should use the clocking wizard in CoreGen as a starting point.
>
> Ed McGettigan
> --
> Xilinx Inc.
Ed,
Thanks for the response. I'm actually using a set of UCF constraints
for the implementation. However, I still need to run a timing
analysis with the newer SDC timing analyzer. In my UCF, I use "PHASE
+ X ns" in my TIMESPEC for a 90 degree phase shift. I'm trying to
determine the equivalent constraint in the SDC format, but I cannot
find any worthwhile documentation on edge_shift.
Anyone else have any documentation they can point me to?
Thanks.
Article: 151426There is a very small chance of doing such task using UDP protocol... Anyway, You better use at least picoblaze for PHY control and let the stream go without the cpu. "hassoo" <husnain_kazimi@n_o_s_p_a_m.hotmail.com> wrote in message news:TtOdnUx-StDT-gHQnZ2dnUVZ_gidnZ2d@giganews.com... > Hi all, > > I am new to the world of FPGA. I want to communicate my Virtex 4 XC4VSX35 > FPGA to PC using Tri-mode Ethernet MAC IP core. Please give me any > suggestion how to start... > Also recommend some basic documentation which helps me understand. > Or if there is any better alternative, plz do share it with me... > > Regards, > Hassoo > > > > --------------------------------------- > Posted through http://www.FPGARelated.comArticle: 151427
On Apr 6, 12:00=A0pm, James <jmos1...@gmail.com> wrote:
> On Apr 6, 11:53=A0am, Ed McGettigan <ed.mcgetti...@xilinx.com> wrote:
>
>
>
>
>
> > On Apr 5, 3:53=A0pm, James <jmos1...@gmail.com> wrote:
>
> > > I want to use create_generated_clock to generate a clock that is half
> > > the frequency of the source clock and also phase shifted by 90
> > > degrees. =A0I'm using Xilinx's new SDC support which does not have th=
e -
> > > phase option that Altera includes. =A0I cannot find ANY worthwhile
> > > documentation on how to specify my edge list for the edge_shift
> > > option. =A0Can someone please help me out? =A0I currently have the
> > > following which may or may not be correct:
>
> > > create_generated_clock \
> > > =A0 =A0 -name my_new_clock \
> > > =A0 =A0 -divide_by 2 \
> > > =A0 =A0 -edges { 1 3 5 } \ =A0 <-- also divides the clock by 2, so th=
e
> > > divide_by option is not really necessary
> > > =A0 =A0 -edge_shift { 1 1 1 } \ =A0<-- not really sure about this par=
t ...
> > > wondering if this is correct
> > > =A0 =A0 -source [get_pins source_clock] \
> > > =A0 =A0 =A0 =A0 =A0 =A0 [get_nets {new_clock}]
>
> > > I know most of the above constraint is correct, but I don't know if I
> > > have specified the edge_shift correctly. =A0Remember, I want to divid=
e
> > > the source_clock by 2 and then shift it by 90 degrees.
>
> > > The best documentation I can find with Google is on Altera's site.htt=
p://www.altera.com/support/software/timequest/clock/tq-generate-cl...
> > > The site provides the following example:
>
> > > # Creates a divide-by-2 clock independent of the master clock's duty
> > > cycle now 50%)
> > > create_generated_clock -source [get_ports clk] -edges { 1 1 5 } -
> > > edge_shift =A00 5 0 } [get_registers clkdivB|clkreg]
>
> > > The above example corresponds to Figure 2 on the linked web page. =A0=
I
> > > don't entirely understand this example or how the edge_shift is {0 5
> > > 0}. =A0It would be great if someone could explain that as well.
>
> > > Thanks for any help.
> > > James
>
> > The SDC constraints can be used to describe timing relationships (as
> > well as other design constraints such as placement locations) for use
> > by the timing analyzer. =A0They cannot be used to drive the tools to
> > create a physical clock condition as it appears you are attempting.
>
> > You should use the clocking wizard in CoreGen as a starting point.
>
> > Ed McGettigan
> > --
> > Xilinx Inc.
>
> Ed,
> Thanks for the response. =A0I'm actually using a set of UCF constraints
> for the implementation. =A0However, I still need to run a timing
> analysis with the newer SDC timing analyzer. =A0In my UCF, I use "PHASE
> + X ns" in my TIMESPEC for a 90 degree phase shift. =A0I'm trying to
> determine the equivalent constraint in the SDC format, but I cannot
> find any worthwhile documentation on edge_shift.
>
> Anyone else have any documentation they can point me to?
>
> Thanks.- Hide quoted text -
>
> - Show quoted text -
This is a constraint that I am not familar with. After a quick
examination of the constraint documentation (UCF) I do see the use of
PHASE along with PERIOD. This should be applied automatically to the
clock outputs from a PLL or DCM with just a PERIOD constraint on the
input to the PLL or DCM.
You said that you were using UCF to implement the design. I can
understand using UCF to constrain the design for timing analyzer, but
not for implementing.
Can you please describe the clocking topology for this design and
which FPGA family you are using?
Ed McGettigan
--
Xilinx Inc.
Article: 151428Hello all, In a seperate thread, there was a brief discussion on what features are needed in a evaluation kit. So related to that, I'm wondering what is the preferred method out there for configuring Virtex 5 and Virtex 6 devices. I"m using commodity parallel flash directly connected to the FPGA. It uses lots of pins but I can program it reasonably fast with the Xilinx tools. Is this the preferred method? Or do some of you use 1) proms 2) CPU 3) systemace or other? Anyone know the 'percentages' of how many users use the different approaches? Cheers! RichArticle: 151429
Rich wrote: > Hello all, > > In a seperate thread, there was a brief discussion on what features > are needed in a evaluation kit. So related to that, I'm wondering > what is the preferred method out there for configuring Virtex 5 and > Virtex 6 devices. I"m using commodity parallel flash directly > connected to the FPGA. It uses lots of pins but I can program it > reasonably fast with the Xilinx tools. Is this the preferred method? > Or do some of you use 1) proms 2) CPU 3) systemace or other? > Anyone know the 'percentages' of how many users use the different > approaches? > > Cheers! > Rich For designs where we don't care about configuration time, i.e. NOT PCI Express, we use commodity SPI flash. Since we almost always end up IO limited, we never use parallel programming modes. For faster startup, we use a separate CPLD connected to possibly multiple SPI flash chips (or fast quad-mode chips) and a 100 MHz crystal oscillator. The CPLD then uses the slave serial mode of the V5 at its 100 MHz maximum rate. By the way this method has uncovered a problem in V5 startup where the DONE pin doesn't rise fast enough for sampling with the 100 MHz clock, so we ended up enabling the "Internal DONE Pipe" to prevent a hang-up issue. Regards, GaborArticle: 151430
On Apr 7, 11:32=A0am, Gabor <ga...@szakacs.invalid> wrote: > Rich wrote: > > Hello all, > > > In a seperate thread, there was a brief discussion on what features > > are needed in a evaluation kit. =A0So related to that, I'm wondering > > what is the preferred method out there for configuring Virtex 5 and > > Virtex 6 devices. =A0I"m using commodity parallel flash directly > > connected to the FPGA. It uses lots of pins but I can program it > > reasonably fast with the Xilinx tools. =A0 Is this the preferred method= ? > > Or do some of you use 1) proms 2) CPU 3) systemace or other? > > Anyone know the 'percentages' of how many users use the different > > approaches? > > > Cheers! > > Rich > > For designs where we don't care about configuration time, i.e. > NOT PCI Express, we use commodity SPI flash. =A0Since we almost > always end up IO limited, we never use parallel programming > modes. =A0For faster startup, we use a separate CPLD connected > to possibly multiple SPI flash chips (or fast quad-mode chips) > and a 100 MHz crystal oscillator. =A0The CPLD then uses the slave > serial mode of the V5 at its 100 MHz maximum rate. =A0By the way > this method has uncovered a problem in V5 startup where the > DONE pin doesn't rise fast enough for sampling with the > 100 MHz clock, so we ended up enabling the "Internal DONE > Pipe" to prevent a hang-up issue. > > Regards, > Gabor Hello Gabor, Great! I learned something new. I did leave out SPI, didnt think of that. I like what you did with multiple SPI and the CPLD. Is there any difficulty in getting the software to program the SPI via IMPACT/ ISE? Regards, RichArticle: 151431
Hassoo, If you are new to the world of FPGAs, please be aware that it is not a trivial task to drop in complicated IP such as an Ethernet MAC. Hopefully you have a board with a fully tested and proven Ethernet interface on it..? There are plenty of development boards out there with a Virtex-4 and Ethernet present. You mentioned alternatives... did you mean alternatives to Ethernet? Depends of course on what you are trying to do, but perhaps a good first step for you (as a beginner) is a serial interface. If you just want to communicate with the FPGA and are not worried about sending / receiving data very quickly, this is orders of magnitude simpler. -- Mike Shogren Director of FPGA Development Epiq Solutions http://www.epiq-solutions.comArticle: 151432
"Mike Shogren" <mike@epiq-solutions.com> wrote in message news:06a6823c-b1b3-4488-9fcf-13cf96d47bc1@f18g2000yqd.googlegroups.com... > Hassoo, > > If you are new to the world of FPGAs, please be aware that it is not a > trivial task to drop in complicated IP such as an Ethernet MAC. > Hopefully you have a board with a fully tested and proven Ethernet > interface on it..? There are plenty of development boards out there > with a Virtex-4 and Ethernet present. What about UDP/RTP packet transmission without softcpu? Are there any references? I would like to stream video over ethernet, so softcpu is not an option.Article: 151433
On Apr 6, 6:14=A0am, "hassoo" <husnain_kazimi@n_o_s_p_a_m.hotmail.com> wrote: > Hi all, > > I am new to the world of FPGA. I want to communicate my Virtex 4 XC4VSX35 > FPGA to PC using Tri-mode Ethernet MAC IP core. Please give me any > suggestion how to start... > Also recommend some basic documentation which helps me understand. > Or if there is any better alternative, plz do share it with me... > > Regards, > Hassoo > > --------------------------------------- =A0 =A0 =A0 =A0 > Posted throughhttp://www.FPGARelated.com I suggest perusing the Xilinx web site looking for application notes that are close to what you want to do. There's Xapp807 - the TEMAC on a Virtex 4. PS: It's spelled "please" - typing the three additional key-strokes will show that you're not lazy.Article: 151434
In article <inku4h$rev$1@dont-email.me>, "scrts" <mailsoc@[remove@here]gmail.com> writes: >What about UDP/RTP packet transmission without softcpu? Are there any >references? I would like to stream video over ethernet, so softcpu is not an >option. It's certainly possible to send UDP packets without a CPU. If you are asking the question, you have a lot of homework to do. I would start by making a pair of programs that send and receive the sort of packets you want to use. Then get out tcpdump/etherreal/wireshark and make sure you understand every bit in the packet. Then get out a scope and make sure you can find those bits on the wire. (That was easier in the old days of coax (thickwire) ethernet since there really was a wire. You might be able to find "the wire" inside an old hub. -- These are my opinions, not necessarily my employer's. I hate spam.Article: 151435
Rich wrote: > On Apr 7, 11:32 am, Gabor <ga...@szakacs.invalid> wrote: >> Rich wrote: >>> Hello all, >>> In a seperate thread, there was a brief discussion on what features >>> are needed in a evaluation kit. So related to that, I'm wondering >>> what is the preferred method out there for configuring Virtex 5 and >>> Virtex 6 devices. I"m using commodity parallel flash directly >>> connected to the FPGA. It uses lots of pins but I can program it >>> reasonably fast with the Xilinx tools. Is this the preferred method? >>> Or do some of you use 1) proms 2) CPU 3) systemace or other? >>> Anyone know the 'percentages' of how many users use the different >>> approaches? >>> Cheers! >>> Rich >> For designs where we don't care about configuration time, i.e. >> NOT PCI Express, we use commodity SPI flash. Since we almost >> always end up IO limited, we never use parallel programming >> modes. For faster startup, we use a separate CPLD connected >> to possibly multiple SPI flash chips (or fast quad-mode chips) >> and a 100 MHz crystal oscillator. The CPLD then uses the slave >> serial mode of the V5 at its 100 MHz maximum rate. By the way >> this method has uncovered a problem in V5 startup where the >> DONE pin doesn't rise fast enough for sampling with the >> 100 MHz clock, so we ended up enabling the "Internal DONE >> Pipe" to prevent a hang-up issue. >> >> Regards, >> Gabor > > Hello Gabor, > Great! I learned something new. I did leave out SPI, didnt think of > that. I like what you did with multiple SPI and the CPLD. Is there > any difficulty in getting the software to program the SPI via IMPACT/ > ISE? > > Regards, > Rich In our case we're not even using Xilinx parts for the CPLD's so we're not programming them with Impact. In fact we use software on an embedded processor to program the flash parts in system. But there's no reason you couldn't come up with a way to use the "direct" SPI program capability of Impact, regardless of the attachment method. You just need a way to get the CPLD out of the circuit when the direct programming cable is plugged in. Regards, GaborArticle: 151436
Hi everyone, I was wondering if anyone here can suggest me a good reference book on PCI express design. I've seen a few on amazon but before buying I'd like to hear your suggestions. ThanksArticle: 151437
>Hi everyone, > >I was wondering if anyone here can suggest me a good reference book on >PCI express design. I've seen a few on amazon but before buying I'd >like to hear your suggestions. > >Thanks > > PCI Express System Architecture is a good book. Its easy to follow and covers everything you would need. Google books have previews of this book and others. Jon --------------------------------------- Posted through http://www.FPGARelated.comArticle: 151438
Hi: I've been developing a DSP+FPGA engine laboratory experiment controller for some years. This summer I have a EE intern coming to help me with hardware and logic development to push toward finishing things. Some things we need to do: 1. Make Xilinx Spartan 3E PCB CAD model (most likely for Eagle). 2. Make Eagle model for TI TMS320F2812 DSP. 3. Top level Verilog module to represent all FPGA IOs used and routing them to sub-modules. 4. Begin developing some sub modules for various functionality. Steps 1, 2, and 3 seem like extremely tedious processes to perform by hand, especially the PCB models, since there are 176 pins on the DSP and may be 200-300 pins on the FPGA depending on the packages we choose. Also, the system plan is to route nearly all DSP IO and memory interface pins to the FPGA, so that the FPGA may be used to reconfigure at any time what specialty DSP IOs appear to the user via a buffered set of BNC connectors. Thus, we will actually use at least >100 FPGA IOs, all which therefore must be coded into the top level Verilog module. What's further boggles my mind is that this is still a relatively simple system, compared to the high end FPGAs and CPUs which may involve >1000 poins each. How is this managed efficiently? Employ grunts? Or should I be looking at the scripting language in Eagle for ex. to attempt to automate the SMD pad placements, at least? Is there a scripting process which can assist this on the Xilinx/Verilog side? Much of this seems difficult to envision how to automate because it is mainly primary data entry, ie., transcribing signal names from the system design and datasheets to pin names in PCB schematic symbols and to FPGA constraint files, which can't be automated. If anything, it might be possible to develop a central file of signal names, pad locations, etc., and have scripts generate the PCB models, Verilog top level module, and constraint file. That way the data entry only needs to be done once. But will the scripting development be just as time consuming as typing everything 3 times? Any ideas on how this is done in the real world would be of interest. -- _____________________ Mr.CRC crobcBOGUS@REMOVETHISsbcglobal.net SuSE 10.3 Linux 2.6.22.17Article: 151439
Mr.CRC wrote: > Hi: > > I've been developing a DSP+FPGA engine laboratory experiment controller > for some years. This summer I have a EE intern coming to help me with > hardware and logic development to push toward finishing things. > > > Some things we need to do: > > 1. Make Xilinx Spartan 3E PCB CAD model (most likely for Eagle). > 2. Make Eagle model for TI TMS320F2812 DSP. > 3. Top level Verilog module to represent all FPGA IOs used and routing > them to sub-modules. > 4. Begin developing some sub modules for various functionality. > > > Steps 1, 2, and 3 seem like extremely tedious processes to perform by > hand, especially the PCB models, since there are 176 pins on the DSP and > may be 200-300 pins on the FPGA depending on the packages we choose. > > Also, the system plan is to route nearly all DSP IO and memory interface > pins to the FPGA, so that the FPGA may be used to reconfigure at any > time what specialty DSP IOs appear to the user via a buffered set of BNC > connectors. Thus, we will actually use at least >100 FPGA IOs, all > which therefore must be coded into the top level Verilog module. > > What's further boggles my mind is that this is still a relatively simple > system, compared to the high end FPGAs and CPUs which may involve >1000 > poins each. > > How is this managed efficiently? Employ grunts? Or should I be looking > at the scripting language in Eagle for ex. to attempt to automate the > SMD pad placements, at least? Is there a scripting process which can > assist this on the Xilinx/Verilog side? > > Much of this seems difficult to envision how to automate because it is > mainly primary data entry, ie., transcribing signal names from the > system design and datasheets to pin names in PCB schematic symbols and > to FPGA constraint files, which can't be automated. > > If anything, it might be possible to develop a central file of signal > names, pad locations, etc., and have scripts generate the PCB models, > Verilog top level module, and constraint file. That way the data entry > only needs to be done once. But will the scripting development be just > as time consuming as typing everything 3 times? > > > Any ideas on how this is done in the real world would be of interest. > > > > I can't speak for Eagle, because we send out our designs for PC layout and the outside house uses PADS. We use ViewDraw (a very old Mentor product) for schematics. You can get some schematic symbols directly from the IC manufacturer *if* you use a popular capture program like Orcad. Perhaps Eagle can import these. Otherwise at least for Xilinx, you can get the ascii pin files which look like spreadsheets. Usually there is a way to import these into a schematic program to automatically generate symbols. Personally I still do this part by hand because I would in any case have to partition the FPGA into individual pieces (Don't even think of doing a 1156-ball part in a single schematic symbol) and I have a preference for the way the symbols are built. With ViewDraw I have some capability to automate pin names/numbers by editing the schematics in a text editor (it's an ASCII file format). I always spend multiple days adding a new part to the library, including checking every pin against both the data sheet and the ASCII pin list (in case there are discrepancies that I might want to ask Xilinx about). As for the .ucf file for using the FPGA after board layout, I automate this using an editor that allows regular expressions and I have macros for taking the ViewDraw netlist and converting it into a .ucf format that uses the same signal names as the schematic. This is a multistep process that first extracts just the board nets that actually go to the FPGA, and then converting the netlist format to the Xilinx constraints. Definitely look into automation in every step of the way. The more you can electronically track your design back to the manufacturer's data the better you'll sleep nights. -- GaborArticle: 151440
Having done similar but smaller designs in gEDA, I find a benefit of using open text files as design files - scripting! I've got a bunch of tools that do symbols, footprints, and UCF files, from spreadsheets. Some folks even generate whole schematic pages from spreadsheets and/or other sources. To get the spreadsheet started, I often cut-n-paste the data sheets and clean it up by hand.Article: 151441
On Apr 8, 12:47=A0pm, "Mr.CRC" <crobcBO...@REMOVETHISsbcglobal.net> wrote: > Hi: > > I've been developing a DSP+FPGA engine laboratory experiment controller > for some years. =A0This summer I have a EE intern coming to help me with > hardware and logic development to push toward finishing things. > > Some things we need to do: > > 1. =A0Make Xilinx Spartan 3E PCB CAD model (most likely for Eagle). > 2. =A0Make Eagle model for TI TMS320F2812 DSP. > 3. =A0Top level Verilog module to represent all FPGA IOs used and routing > them to sub-modules. > 4. =A0Begin developing some sub modules for various functionality. > > Steps 1, 2, and 3 seem like extremely tedious processes to perform by > hand, especially the PCB models, since there are 176 pins on the DSP and > may be 200-300 pins on the FPGA depending on the packages we choose. > The PCB model can be attacked in a couple of ways: - 'Roll your own' model. This is handy when you don't have a CAD model yet but you need to test your FPGA code. - Use a PCB CAD model generated by the CAD tools. Check to see if your tools allow you to export the schematic as VHDL or Verilog. We used Cadence and it saved the VHDL/Verilog netlist whenever the schematic was saved. There are plusses and minuses with both methods. The 'roll your own' is obviously prone to errors where the model differs from the real PCB schematic. It will also take longer to create since you'll be doing it by hand versus the CAD tool export which will be essentially 'free' (assuming that the CAD tool rewrites the file with each save of the schematic). In spite of this, you may find that you can get to a reasonably accurate model quicker with this method than with the PCB CAD generated model. The CAD tool generated model will accurately reflect the actual PCB design. You'll probably find the high fidelity to be both the best and worst part of this approach. The stumbling points will have to do with the most mundane components. I work in VHDL where I solve these problems mainly with the VHDL configuration statement, I don't know what facilities Verilog may have, but here are some of the 'gotchas' and their VHDL work arounds: - Series terminated clock signal heading into a model that expects the clock to switch to a '1', not an 'H'. WA=3Dupdate model to use 'rising_edge()' function instead or use the 'to_x01()' function in the port map - Parallel termination to two different voltage levels (i.e. 220 ohm to +5V; 330 ohm to ground as an example). This situation creates an unknown at the tie point. WA=3DUse configuration statement to turn one of the resistors into an open circuit model (more on that later). - Terminating a differential pair with a resistor across the pair. WA=3DUse configuration statement to turn the resistor into an open circuit model - Open pins connected to a 'bus' of pins on a model. For example, a processor that has a 16 bit data bus, the model has the bus named DATA(15 downto 0), but only an 8 bit bus is needed and it is acceptable to leave the unused pins unconnected to the device. VHDL says that this is an error, maybe Verilog does not. WA=3DConnect one pin nets on the schematic. That doesn't result in any actual copper on the board to route and gets around this language limitation. WA2=3DChange the model so that there are 16 individual pins (D15, D14...D0). - Series blocking capacitors. Usually the simulation model you want for a capacitor is an open circuit, drive both pins with a 'Z'. In this case though you need the capacitor to behave as a short circuit connecting the 'input' to the 'output'. - Passives sometimes need 'direction'. In the case of series connected passives, if the models cannot tolerate momentary transitions to 'X', then you need to make these parts 'one-way' with a specific input and output pin. Typically this will come up with a series terminated clock signal. The transition from '0' to 'X' to '1' will not be a 'rising edge'. WA=3DAgain use configurations for the specific components that have this issue and use a model that only propogates signals in one direction. You'll also want the person entering the schematic to not be flipping the ends of the resistor around on you a lot, and it would help if they oriented these 'one way' resistors consistently. - You need to model *everything*. Whereas with the 'roll your own' approach, you'll typically only model and connect the 'important' parts, with the CAD model, you'll get every resistor, capacitor, diode, transistor, varistor, fuse, blah, blah, blah...and in order to simulate anything you'll need models for all of those parts. That's the bad news. The good news is that for many of the parts you can probably get away with a brain dead model which simply drives all outputs and I/O to 'Z' and those are really quick to create. The exception will be some of the cases mentioned above. You'll definitely need several different models for resistors and have to use some facility to select the appropriate model to use since the CAD generated netlist will instantiate the exact same 'res' component. - A part that does not physically fit on to a single page so it must be broken up into sections and instantiated on separate physical pages. WA=3DThis is the only case where I don't have a work around that doesn't involve editing the CAD generated model. The CAD model will instantiate XX separate sections with their individual set of I/O pins. The problem is that from a simulation perspective, these need to be a single instantiation. What I did here is to re-arrange the ordering of the instantiations of the individual sections so that they are one right after another and then join the various sections up so that they are all one instantation in the PCB model. This process must be repeated whenever the schematic is updated. No matter which approach you take, you'll need models for parts. If you currently have none, start building up your library now. There are sources. For 'important' parts, you can find models either from the manufacturer, or web sources such as Free Model Foundry (http:// www.freemodelfoundry.com/). Be careful with memory models, in particular flash or other large non-volatiles. Using those models might require more memory than can be allocated for the simulation. For others, and definitely for the 'not so important' parts, start with a 'simple parts library' where you hand generate the model for the part. It's a bit tedious when you have a long list of parts, but this library can be reused in future designs, and the models for these parts can improve over time. The initial cut at simply assigning all outputs and I/O to 'Z' is simply an exercise in cut/paste that must be done...but it is pretty quick (~1 minute or less) per component once you get into the swing of it. For your first project, maybe those 'not so important' parts can live with no real model, but now you have all of the infrastructure in place to enhance the model later for some future project where maybe the part isn't 'not so important'. > Also, the system plan is to route nearly all DSP IO and memory interface > pins to the FPGA, so that the FPGA may be used to reconfigure at any > time what specialty DSP IOs appear to the user via a buffered set of BNC > connectors. =A0Thus, we will actually use at least >100 FPGA IOs, all > which therefore must be coded into the top level Verilog module. > What is the question? The top level module would always have to have every I/O pin. That's a one time thing for any design. Creating the top level entity shouldn't take more than a few minutes. Since it is the 'top level', the interface will not be changing frequently since that implies that the circuit board would as well. > > How is this managed efficiently? =A0Employ grunts? =A0Or should I be look= ing > at the scripting language in Eagle for ex. to attempt to automate the > SMD pad placements, at least? =A0Is there a scripting process which can > assist this on the Xilinx/Verilog side? > > Much of this seems difficult to envision how to automate because it is > mainly primary data entry, ie., transcribing signal names from the > system design and datasheets to pin names in PCB schematic symbols and > to FPGA constraint files, which can't be automated. > One approach that I've found useful is simply to use Excel. There will be several different tools that will all need different 'things' that are all related to the pin names in the design. Creating Excel formulas so that each column performs some useful calculation will allow this spreadsheet to be a kind of 'golden reference' of information. Starting from a spreadsheet that lists design specific pin names, their direction (in/out/inout) and the appropriate pin number some examples of things you can put into the various columns are: - Timing requirements. Inputs should have setup times, outputs should have Tco or Tpd requirements. Create a formula that generates the TCL command that can be copy/pasted into your FPGA tool to define them. - I/O drive strength. Again, create a formula to create a TCL command for the FPGA tool - Map the pin number to the CAD model's pin name. The CAD model for the FPGA will have the manufacturer's pin name such as "IO1", "IO2"...etc. At some point, you will need to create a design specific FPGA model that maps those entity names to your FPGA design. The port mappings can be computed in the spreadsheet, copy and paste them into your design specific FPGA model. You'll need a page in your Excel file that lists the CAD pin names used and their pin numbers. Once the CAD people have created the symbol and PCB files, you should be able to suck that into a new page in Excel. Then you can use Excel's lookup functions to search for the pin number and return the CAD name. This CAD page in Excel would not be design specific, you can use it for any new design that uses that same component. There are others as well, but the basic idea is to have the Excel file be the reference...although it will be tempting to bypass this at times, mostly in the timing requirements area after the initial load. Even if you're not totally religious about keeping the spreadsheet accurate it gets you off to a big start. On the next project, since you now have the spreadsheet with all those formulas, all you will have to do is populate a new spreadsheet with the new design signal names, signal direction and pin numbers for a new design and you'll immediately have everything you need since the formulas won't need any tweaking...well, as long as the format of the input to the tools doesn't vary over time (but it will...but usually not that much). > If anything, it might be possible to develop a central file of signal > names, pad locations, etc., and have scripts generate the PCB models, > Verilog top level module, and constraint file. =A0That way the data entry > only needs to be done once. =A0But will the scripting development be just > as time consuming as typing everything 3 times? > Generating the spreadsheet and then using that to copy/paste into the tools will likely take just about as long as using the tools directly or a bit longer...but only the first time you do it this way. The advantage will be with the *next* design since you'll have all the pieces in place to simply populate a couple columns of the spreadsheet. Disadvantages of scripts has to do with the scripting language and whether you have, and will continue to have in the future, expertise in the scripting language itself. The learning curve for Excel formulas should be lower than a scripting language. > Any ideas on how this is done in the real world would be of interest. > Hopefully given you at least a few good ideas. Kevin JenningsArticle: 151442
On 8 avr, 04:19, "maxascent" <maxascent@n_o_s_p_a_m.n_o_s_p_a_m.yahoo.co.uk> wrote: > >Hi everyone, > > >I was wondering if anyone here can suggest me a good reference book on > >PCI express design. I've seen a few on amazon but before buying I'd > >like to hear your suggestions. > > >Thanks > > PCI Express System Architecture is a good book. Its easy to follow and > covers everything you would need. Google books have previews of this book > and others. > > Jon =A0 =A0 =A0 =A0 > > --------------------------------------- =A0 =A0 =A0 =A0 > Posted throughhttp://www.FPGARelated.com Thank you! I think i'll buy this one!Article: 151443
"Mr.CRC" <crobcBOGUS@REMOVETHISsbcglobal.net> wrote: >Hi: > >I've been developing a DSP+FPGA engine laboratory experiment controller >for some years. This summer I have a EE intern coming to help me with >hardware and logic development to push toward finishing things. > > >Some things we need to do: > >1. Make Xilinx Spartan 3E PCB CAD model (most likely for Eagle). >2. Make Eagle model for TI TMS320F2812 DSP. >3. Top level Verilog module to represent all FPGA IOs used and routing >them to sub-modules. >4. Begin developing some sub modules for various functionality. > > >Steps 1, 2, and 3 seem like extremely tedious processes to perform by >hand, especially the PCB models, since there are 176 pins on the DSP and >may be 200-300 pins on the FPGA depending on the packages we choose. > >Also, the system plan is to route nearly all DSP IO and memory interface >pins to the FPGA, so that the FPGA may be used to reconfigure at any >time what specialty DSP IOs appear to the user via a buffered set of BNC >connectors. Thus, we will actually use at least >100 FPGA IOs, all >which therefore must be coded into the top level Verilog module. > >What's further boggles my mind is that this is still a relatively simple >system, compared to the high end FPGAs and CPUs which may involve >1000 >poins each. > >How is this managed efficiently? Employ grunts? Or should I be looking >at the scripting language in Eagle for ex. to attempt to automate the >SMD pad placements, at least? PCB packages often have a pin array generator which helps creating BGA, QFP and QFN layouts. The opensource Geda/PCB package allow creating footprints and parts by scripts because those are defined in simple text files. > Is there a scripting process which can >assist this on the Xilinx/Verilog side? IIRC Xilinx has Excel sheets which you could convert to text files. >Much of this seems difficult to envision how to automate because it is >mainly primary data entry, ie., transcribing signal names from the >system design and datasheets to pin names in PCB schematic symbols and >to FPGA constraint files, which can't be automated. > >If anything, it might be possible to develop a central file of signal >names, pad locations, etc., and have scripts generate the PCB models, >Verilog top level module, and constraint file. That way the data entry >only needs to be done once. But will the scripting development be just >as time consuming as typing everything 3 times? Developing scripts is an insurance premium against errors. Developing a script takes a -more or less- predictable amount of time. Finding an error in the pinout takes a variable amount of time. -- Failure does not prove something is impossible, failure simply indicates you are not using the right tools... nico@nctdevpuntnl (punt=.) --------------------------------------------------------------Article: 151444
Hi, i am trying to ake use of OC Pci Bridge on my designe, and finally i could make it work as i want. I can master the network and receive/ send bursts of data on Linux. But i need a sugestion now. I need to transfer some data to computer, and to tell it when the transfer is done i will generate a interrupt. My question is.. when i finish transfer data from my wishbone master to the slave at the bridge, it does not mean that all the data was transfered to the computer.. so how can i know when all the data is at the computer's memory, so i can generate the interrupt? Thank you, let me know if i was not enough clear.Article: 151445
On Fri, 08 Apr 2011 09:47:55 -0700, Mr.CRC wrote: > Hi: > > I've been developing a DSP+FPGA engine laboratory experiment controller > for some years. This summer I have a EE intern coming to help me with > hardware and logic development to push toward finishing things. > > > Some things we need to do: > > 1. Make Xilinx Spartan 3E PCB CAD model (most likely for Eagle). 2. > Make Eagle model for TI TMS320F2812 DSP. 3. Top level Verilog module to > represent all FPGA IOs used and routing them to sub-modules. > 4. Begin developing some sub modules for various functionality. > > > Steps 1, 2, and 3 seem like extremely tedious processes to perform by > hand, especially the PCB models, since there are 176 pins on the DSP and > may be 200-300 pins on the FPGA depending on the packages we choose. > > Also, the system plan is to route nearly all DSP IO and memory interface > pins to the FPGA, so that the FPGA may be used to reconfigure at any > time what specialty DSP IOs appear to the user via a buffered set of BNC > connectors. Thus, we will actually use at least >100 FPGA IOs, all > which therefore must be coded into the top level Verilog module. > > What's further boggles my mind is that this is still a relatively simple > system, compared to the high end FPGAs and CPUs which may involve >1000 > poins each. > > How is this managed efficiently? Employ grunts? Or should I be looking > at the scripting language in Eagle for ex. to attempt to automate the > SMD pad placements, at least? Is there a scripting process which can > assist this on the Xilinx/Verilog side? > > Much of this seems difficult to envision how to automate because it is > mainly primary data entry, ie., transcribing signal names from the > system design and datasheets to pin names in PCB schematic symbols and > to FPGA constraint files, which can't be automated. > > If anything, it might be possible to develop a central file of signal > names, pad locations, etc., and have scripts generate the PCB models, > Verilog top level module, and constraint file. That way the data entry > only needs to be done once. But will the scripting development be just > as time consuming as typing everything 3 times? > > > Any ideas on how this is done in the real world would be of interest. Steps 1 & 2 should only take a day -- two if you can't find package models in the Eagle libraries already. It'll take you longer than that to hire someone. -- http://www.wescottdesign.comArticle: 151446
On Apr 1, 11:14=A0pm, Rob Gaddi <rga...@technologyhighland.com> wrote: > I'm working on a Spartan 3 design and trying to figure out how, if at > all, I can constrain what I'm looking for without resorting to hand > placement and directed routing. > > I've got an analog pulse that feeds 4 comparators with different > thresholds. =A0This gives me 4 pulses of which each narrower one is > contained entirely in time by each wider one, like the side view of the > Towers of Hanoi experiment. =A0The widest will be 3-4 ns, the narrowest > will be narrow enough to not consistently be able to trip the internal > flops. =A0They'll be coming in at up to 80 MHz. > > Given that this is pretty fast for an S3, I've lit on the idea of using > each pulse to clock a T-flop, then resynchronize the output of the T at > 200 MHz into an XOR change detector; the classic pulse-toggle-pulse > domain crosser but directly clocked rather than clock enabled. =A0Code > (untested) at the end of this message. > > So I've got a 2 ns event (rising edges only) and a 5 ns clock period. =A0= I > need to make sure that all of my resynchronized pulses come out during > clock cycle n or n+1. =A0Which, so near as I can figure, means that I wan= t > to have no more than 3 ns of routing delay skew on these signals, from > the pins through the Ts to the D input on the first synchronizer stage. > > Anyone have the foggiest how to bully the tools into pulling this off? > > Thanks, > Rob > > Rob Gaddi, Highland Technology > Email address is currently out of order I haven't done this in the Xilinx flow, but if does support virtual clocks, than that would be the way to do it ... Assign virtual clocks to the analog inputs and to the destination flops, that set proper period and clock relationships, and it should do what you want ... Regards, rudiArticle: 151447
On Mar 5, 5:36=A0pm, Jason Luska <jasonlu...@gmail.com> wrote: > Hi Guys, > > Hope one of you guys can help me out here. I have to supply a client a > IP core that we have developed but we don't want to give the VHDL > source. I have a few questions regarding delivery format. The core > will run on a Xilinx FPGA. > > 1) Would the NGC file out of the synthesizer be the most appropriate > delivery format? > 2) How safe is NGC file (in regards to reverse-engineering)? > 3) Can a NGC file synthesized for one device, say Spartan 3A DSP, be > used in a design that targets another device, say Virtex4? > > 4) The IP core port has few GENERICS to configure the core. It looks > like once the core has been synthesised (standalone) the generics are > fixed to the default values and the design that uses the IP core (as a > NGC file) is not able to change generics. ISE throws the following > warning: > > Reading core <MA_FILTER.ngc>. > WARNING:Xst:1474 - Core <MA_FILTER> was not loaded for <MA_FILTER_1> > as one or more ports did not line up with component declaration. > Declared input port <DATA_IN<17>> was not found in the core. =A0Please > make sure that component declaration ports are consistent with the > core ports including direction and bus-naming conventions. > > WARNING:Xst:616 - Invalid property "gAVG_LEN 8": Did not attach to > MA_FILTER_1. > WARNING:Xst:616 - Invalid property "gIN_LEN 18": Did not attach to > MA_FILTER_1. > > How can the design that uses the core be able to pass in GENERICS? > > 5) The core uses a custom package and the design that uses the core > would also like to use the same package (there are few functions that > the toplevel design would like to use). How do you deliver the package > without giving the VHDL source? > > 6) The client would like to be able to simulate the core in their > design using Modelsim. What needs to be provided to allow this? A > search on google resulted in pre-compiled library but I couldn't find > anything on how to generate a pre-compiled library for a core. Is the > pre-compiled library the way to go? > > Thanks in advance > > Jason. Jason, there is no true security. Regardless of what you deliver. The questions you have to ask yourself is how motivated is your client in reverse engineering the IP Core ? Typically, if you are clever enough to reverse engineer an IP Core, you might as well write it yourself. If the IP Core is rather trivial and small it will be easy to reverse engineer it and get pretty close to the original source code. The more complex an IP Core is, the harder it is to reverse engineer it and make sense out what you get. The IP Core Source Code is typically only 1/4 of the value of an IP Core. Other parts are Test Bench, Documentation, Certification and 3rd party hardware validation, and most of all tech support. Good Luck, rudiArticle: 151448
FYI: Altium limited has laid off 60% of their staff and will be closing the australia offices by the end of the month.Article: 151449
Rikard Astrof wrote: > FYI: Altium limited has laid off 60% of their staff and will be > closing the australia offices by the end of the month. April 1 is over :-) Do you have a link? Last time I tried Altium Designer it was a nice program. Of course expensive and with some bugs, but would be bad for many people who are using it if it will be discontinued. -- Frank Buss, http://www.frank-buss.de piano and more: http://www.youtube.com/user/frankbuss
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