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
In my design I've used the following structure to control the output tri-state... host_data <= host_data_out when host_dout_en = '1' else "ZZ....ZZZZ"; host_data_out and host_dout_en are both registers generated in the same state machine in a lower level module. The tools won't place these both in IOB registers. The IO structure shown in the ProAsic3 handbook would suggest that this should be possible/easy. Any ideas anyone? NialArticle: 135601
Hello, I feel your pain - I had exactly the same problem on an Actel PA3E design. In my case, the issue was that Synplify Pro would not ever infer IOB registers. Thus, I had to rely on the Actel Designer Combiner IOB-stuffing option to get any IOB registers at all. Do you have that turned on? If you do, check how you describe host_data_out and host_data_en. Actel PA3 IOB flip-flops are very boring - they don't have a synchronous clear or synchronous preset input. If you're describing either of those, the register probably won't be pushed into the IOB. My recommended method is to have host_data_out and host_dout_en be described as a flip-flop without any resets/clears/ loads/presets so that Synplify will infer a "plain" flip-flop that then can be pushed into the IOB by Designer Combiner. Good luck, Nathan On Oct 9, 7:17=A0am, "Nial Stewart" <nial*REMOVE_TH...@nialstewartdevelopments.co.uk> wrote: > In my design I've used the following structure to control the > output tri-state... > > host_data <=3D host_data_out when host_dout_en =3D '1' else "ZZ....ZZZZ"; > > host_data_out and host_dout_en are both registers generated in the > same state machine in a lower level module. > > The tools won't place these both in IOB registers. > > The IO structure shown in the ProAsic3 handbook would suggest that > this should be possible/easy. > > Any ideas anyone? > > NialArticle: 135602
Xess (http://www.xess.com/) has some really practical and inexpensive boards for a beginner or experimenter. DerekArticle: 135603
Thanks Rob, Gabor, and KJ. Converting from records to std_logic_vector isn't the issue because my objective was to be able to see the entire bram memory in ModelSim. Late last night I implemented dual memories as Gabor suggested, one for sim and one for syn. I too am wondering why ISE can't infer other types. Just checking with the group to see if I was missing something. Thanks. Brad Smallridge Ai VisionArticle: 135604
Nial Stewart a écrit : > In my design I've used the following structure to control the > output tri-state... > > > host_data <= host_data_out when host_dout_en = '1' else "ZZ....ZZZZ"; > > > host_data_out and host_dout_en are both registers generated in the > same state machine in a lower level module. > > The tools won't place these both in IOB registers. Hi I have no experience with Actel but I may have a clue. host_dout_en is a single bit register, whereas host_data_out is a vector. If the tool isn't smart enough to replicate the enable register it won't be possible to put it in an IOB. Try to define your enable as a vector and use a for...generate loop to control each individual bit of your output vector. NicolasArticle: 135605
Hi Folks, altough brand new I hope someone already made some experience with Virtex-5. I just switched from Virtex-4 to Virtex-5 and I must admit that the clock managment is... and remains... somewhat unclear to me! It's plain to see that the clock management is handled a bit differently than Virtex-4. Virtex-5 clocking uses both DCM (digital clock managers) technology for delay control and PLL (phased lock loop) technology for lower jitter clock generation. But what does that mean to me, practically? What should I account for when designing a PCB with Virtex-5? Which IOs am I supposed to use? In Virtex-4 I had Global Clock and Regional Clock Inputs. So far so good. In Virtex-5 I have plenty of different clock inputs and it is almost impossible to arrange for an optimal clock management at the time prior to developing the internal VHDL logic for the FPGA. Basically I'd like to know how to connect my global clock sources to the FPGA without catching problems later in implementing the VHDL and getting confronted with timing errors, etc. Same problem - still much worse - with the RocketIO reference clocks! Plenty of clock inputs but. much too confusing! For example I'd like to take one reference clock for an arrangement of 10 RocketIOs. No problem with Virtex-II pro, no problem with Virtex-4, big problem with Virtex-5 for the clocks can only supply 4 RocketIOs at once... as far as I can judge. Still, I may be wrong! So any help is highly appreciated. SaulArticle: 135606
I am banging my head against some timing problem with some XC3S500E
design. A XC2V500 doesn't behave much different.
While the delay estimation given by XST seems sensible:
Timing Summary:
---------------
Speed Grade: -4
Minimum period: 12.021ns (Maximum Frequency: 83.188MHz)
Minimum input arrival time before clock: 6.695ns
Maximum output required time after clock: 4.283ns
Maximum combinational path delay: 5.310ns
Timing Detail:
--------------
All values displayed in nanoseconds (ns)
=========================================================================
Timing constraint: Default period analysis for Clock 'clk'
Clock period: 12.021ns (frequency: 83.188MHz)
Total number of paths / destination ports: 155688 / 317
-------------------------------------------------------------------------
Delay: 12.021ns (Levels of Logic = 5)
Source: hf_ctl/const_mem (RAM)
Destination: hf_ctl/const_mem (RAM)
Source Clock: clk rising
Destination Clock: clk rising
Data Path: hf_ctl/const_mem to hf_ctl/const_mem
Gate Net
Cell:in->out fanout Delay Delay Logical Name (Net Name)
---------------------------------------- ------------
RAMB16_S36_S36:CLKA->DOA17 9 0.012 0.820 hf_ctl/const_mem (read_const<17>)
MULT18X18SIO:B17->P18 2 4.873 0.622 hf0/Mmult_multk_data (hf0/multk_data<18>)
LUT4:I0->O 1 0.704 0.424 hf0/Mxor_ov_multm_raw_xo<0> (hf0/Mxor_ov_multm_raw_xo<0>)
LUT4:I3->O 18 0.704 1.068 hf0/Mxor_ov_multm_raw_xo<3> (hf0/ov_multm_raw)
MUXF5:S->O 1 0.739 0.455 hf0/Mmux_write_var_54 (hf0/Mmux_write_var_54)
LUT3:I2->O 6 0.704 0.669 hf0/write_var<11>_inv1 (write_var<11>)
RAMB16_S36_S36:DIB11 0.227 hf_ctl/const_mem
----------------------------------------
Total 12.021ns (7.963ns logic, 4.058ns route)
(66.2% logic, 33.8% route)
the report given by trace is about 50 % higher a similar path (up to write_var<11>)
155688 paths analyzed, 371 endpoints analyzed, 137 failing endpoints
137 timing errors detected. (137 setup errors, 0 hold errors)
Minimum period is 17.063ns.
--------------------------------------------------------------------------------
Slack: -4.563ns (requirement - (data path - clock path skew + uncertainty))
Source: hf_ctl/const_mem.A (RAM)
Destination: hf0/data_r2_11 (FF)
Requirement: 12.500ns
Data Path Delay: 17.063ns (Levels of Logic = 5)
Clock Path Skew: 0.000ns
Source Clock: clk_BUFGP rising at 0.000ns
Destination Clock: clk_BUFGP rising at 12.500ns
Clock Uncertainty: 0.000ns
Maximum Data Path: hf_ctl/const_mem.A to hf0/data_r2_11
Location Delay type Delay(ns) Physical Resource
Logical Resource(s)
------------------------------------------------- -------------------
RAMB16_X1Y1.DOA17 Tbcko 2.812 hf_ctl/const_mem
hf_ctl/const_mem.A
MULT18X18_X1Y2.B17 net (fanout=9) 1.604 read_const<17>
MULT18X18_X1Y2.P23 Tmult 4.873 hf0/Mmult_multk_data
hf0/Mmult_multk_data
SLICE_X54Y22.G2 net (fanout=2) 1.502 hf0/multk_data<23>
SLICE_X54Y22.Y Tilo 0.759 hf_ctl/op_bits_r<15>
hf0/Mxor_ov_multm_raw_xo<1>
SLICE_X54Y22.F4 net (fanout=3) 0.030 hf0/Mxor_ov_multm_raw_xo<1>/O
SLICE_X54Y22.X Tilo 0.759 hf_ctl/op_bits_r<15>
hf0/Mxor_ov_multm_raw_xo<3>
SLICE_X66Y24.BX net (fanout=16) 0.904 hf0/ov_multm_raw
SLICE_X66Y24.X Tbxx 0.806 hf0/Mmux_write_var_54
hf0/Mmux_write_var_54
SLICE_X65Y11.F2 net (fanout=1) 0.995 hf0/Mmux_write_var_54
SLICE_X65Y11.X Tilo 0.704 hf_ctl/write_var_r<11>
hf0/write_var<11>_inv1
SLICE_X65Y3.BY net (fanout=5) 0.954 write_var<11>
SLICE_X65Y3.CLK Tdick 0.361 hf0/data_r2<11>
hf0/data_r2_11
------------------------------------------------- ---------------------------
Total 17.063ns (11.074ns logic, 5.989ns route)
(64.9% logic, 35.1% route)
Data sources are BRAM, here this data is fed into a MULT18X18, some clipping
is performed and a 8:1 multiplexer feeds the result back to the blockram.
I used following contraint:
NET "clk" TNM_NET = "CLK";
TIMESPEC "TS_clk" = PERIOD "CLK" 80 MHz HIGH 50 %;
Do I miss some settings?
Do I missinterpret something?
Thanks
--
Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de
Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------
Article: 135607Saul Bernstein wrote: > > Same problem - still much worse - with the RocketIO reference clocks! Plenty > of clock inputs but. much too confusing! For example I'd like to take one > reference clock for an arrangement of 10 RocketIOs. No problem with > Virtex-II pro, no problem with Virtex-4, big problem with Virtex-5 for the > clocks can only supply 4 RocketIOs at once... as far as I can judge. > The Virtex-5 MGT REFCLK inputs can span up and down 3 of the GTP_DUAL or GTX_DUAL sites, so you can reach 7 DUALs or 14 lanes. Ed McGettigan -- Xilinx Inc.Article: 135608
Hi, Im trying to instantiate two DSP blocks in the virtex FPGA but keep getting the following errors. Mapping design into LUTs... ERROR:LIT:398 - PCIN bus of DSP48E symbol "MAC_1a/DSP_1/DSP48E_INST" can be sourced only by a PCOUT bus of a different DSP48E block. ERROR:LIT:416 - ACIN bus of DSP48E symbol "MAC_1a/DSP_1/DSP48E_INST" can be sourced only by ACOUT bus of a different DSP48E. ERROR:LIT:400 - BCIN bus of DSP48E symbol "MAC_1a/DSP_1/DSP48E_INST" can be sourced only by BCOUT bus of a different DSP48E. This is my first time using DSP48E, maybe Im doing something wrong. All Im trying to do is instantiate 2 DSPs ... 1st one that gets inputs from higher level Ain, bin etc and provided cascaded outputs to the second one ... the second instantiation has ACIN, BCIN and PCIN as inputs ... code is pasted below DSP_1: DSP PORT MAP ( A_IN => ain, B_IN => bin, CE_IN => not en, CLK_IN => clk, C_IN => (OTHERS => '0'), RST_IN => rst, ACOUT_OUT => A_in_1, BCOUT_OUT => B_in_1, PCOUT_OUT => P_Out_1, P_OUT => open); DSP_2: DSP_cas PORT MAP ( ACIN_IN =>A_in_1, BCIN_IN =>B_in_1, CE_IN => not en, CLK_IN =>clk, PCIN_IN => P_Out_1, RST_IN => rst, P_OUT => dout); Any help would be appreciated or maybe an example instantiation.Thanks.Article: 135609
Hello All, I am fighting with a strange problem that I have with rebuilding hardware and/or adding new IP for Spartan3E, and looking for your advices... I tried the reference design of hardware for Spartan 3E in petalinux archive and compile it with EDK. This hardware works fine and I could bootup the Linux and play with it. But problem starts when I try to add a new IP core to the design. After adding new IP (which is just a hardware to turn on an LED on the board) to design, the only way to make it work is to "clean hardware" in EDK and rebuilt everything (which seems it is the correct way). Sounds good, but hardware works (I mean LED goes on as I wish) and fs- boot (if you are familiar with it, the first bootloader for loading u- boot) also works. But the problem now is after loading u-boot by fs- boot, u-boot is not working. So seems that compiling the design from a copy of refrence design in peta-linux archive, works. But rebulding it again doesn't work. So my question is, why when I build the hardware for the first time it works, but after "clean hardware" and compile it again (even without adding new IP) doesn't work? Looking for any advice and suggestion. Regards,Article: 135610
Hi everybody, First off all...sorry for cross posting this to both arch.fpga and arch.embedded, but I think it fits in both places. I'm currently in the selection fase of an FPGA vendor. we need a >2M gate chip with DSP capabilities, SERDES and offcourse the mandatory low cost. Likewise we need a high performance embedded CPU softcore for system management. At the moment things are pointing towards lattice because of price, availability and HW specs. As i'm involved in the SW part of the design me and my team has been trying to evaluate the tool chain (ispLEVER + Eclipse Mico32 environment) and the evaluation board bassed on a Lattice ECP2 FPGA. But we're not quite happy about it. We have spend allot of time to get a very simple CPU system (CPU + intern memory) running on the FPGA. We have done progress but this is very slow and we seem to keep banging our heads against the wall when we try expand the system. My conclusions on the Lattice tool chain and the Mico32 system based on the evaluation is as follows: * Bad documentation on both tools and eval boards. Some stuff will never work if you don't reverse engineer HW or get correct support. * Outdated tutorials regarding to tool and HW revisions. * Poorly integrated and bugy tools. * Extremely slow JTAG connection to the CPU (19kbit/sec) for SW debugging/downloading. * Hard to trouple shot the CPU configuration (e.g. SW debugger cannot connect to the CPU). * Tools crashes * Overall poorly matured product (Mico32 and tools). So my questions are: * Is it only me that have come to this conclusion? Are some of you using lattice and Mico32 with success in a commercial product? * Any ways (known fixes to issues, third party stuff etc.) to get faster to market with the Lattice solution? * Is the stuff (NIOS II and tools) from Altera (or any other vendor) any better regarding the complaints above? * The Mico32 is open source but is the origin of the code made by Lattice themselves or? * Any recommendations or experiences to share? Hope to see some comments on my conclusions and questions. Thank you! Best Regards -- MMJ PS: All in this message is my personal opinions - and may not be the ones of my employer.Article: 135611
FreeWheel wrote: > * Is the stuff (NIOS II and tools) from Altera (or any other vendor) > any better regarding the complaints above? There are cheap evaluation kits with NIOS II integrated available, so maybe you should try it yourself. I've used it for a commercial product with a Cyclone, but I wouldn't do it again. It is possible and there are some nice IPs, but the price of a FPGA with all the IPs you'll need for a good system (CPU core, SDRAM/network/UART etc.) is higher than buying it in a hardwired microcontroller, like one of this ones, if you don't need already big parts of the FPGA for FPGA related things, and the NIOS II would be just a small offset to the whole system. http://www.st.com/inchtml-pages-stm32.html http://www.standardics.nxp.com/microcontrollers/ (the LPC series is nice) http://www.atmel.com/products/at91/ And using NIOS II is sometimes tricky (see http://forum.niosforum.com/forum/index.php?showforum=2 for some interesting forum posts). Things which are easy with hardwired microcontrollers sometimes gets difficult with NIOS. There were even CPU core bugs in older versions of NIOS and the development environment is bloated and slow. The SoPC builder is powerful, but it is complicated to configure the system (sometimes you have to configure some special attributes of a component and failing to do so results in strange compiling errors), the right busses, arbitraters etc. and route it to a working system. In theory I like the idea of using just one FPGA to build your whole system, but I think a micorcontroller is better: No costs for additional IPs, DSP functions in the bigger ones included, all hardware you'll need included in tested hardwired blocks, if you choose the right one and free tools like GCC for fast ARM CPUs etc. makes live much easier. Use an additional FPGA for the parts which needs a FPGA, e.g. routing many fast signals, additional DSP functions etc. and attach it to the microcontroller with a memory mapped interface for more complex systems, or a simpler interface. -- Frank Buss, fb@frank-buss.de http://www.frank-buss.de, http://www.it4-systems.deArticle: 135612
Frank Buss wrote: > and free > tools like GCC for fast ARM CPUs etc. makes live much easier. Did I mention that the professional version of the Altera software license expires after one year and you have to renew it every year (for $2,495), if you want to do bugfixes later in your designs? Last time I used it, you couldn't use NIOS with the free web edition. Compare this to a ARM-GCC-Eclipse toolchain or the free Symphony Studio IDE for the nice Freescale DSPs. -- Frank Buss, fb@frank-buss.de http://www.frank-buss.de, http://www.it4-systems.deArticle: 135613
On Oct 8, 4:01=A0pm, Selensky <selen...@gmail.com> wrote: > On 8 out, 18:31, Peter Alfke <pe...@xilinx.com> wrote: > > > > > On Oct 8, 12:46=A0pm, Thomas Heller <thel...@python.net> wrote: > > > > Peter Alfke schrieb: > > > > [Ah, back again?] > > > > > On Oct 8, 7:35 am, Pratap <pratap.i...@gmail.com> wrote: > > > >> Hi, > > > >> I want to synthesize a delay of around 10 ns in Xilinx Virtex2 Pro= . So > > > >> I put around 200 inverters in series and get the desired delay. So= I > > > >> did port map the BASIC cell "INV" according to the XST settings. > > > >> But when i place and route I guess the optimizer removes all the > > > >> intermediate buffers and I get very less delay when I do a post ro= ute > > > >> simulation. > > > >> How can I get rid of this problem? > > > >> Thanks in advance. > > > >> -Pratap > > > > > Use the IDELAY in Xilinx Virtex-4 or later. It gives you max 5 ns > > > > delay, but that delay is stable over temperature, voltage, and > > > > processing, because it is referenced to a 200 MHz clock (I call tha= t > > > > servo-stabilized). > > > > Peter Alfke, Xilinx > > > > Which jitter does this give? > > > > Thanks, > > > Thomas > > > Very little, since this is really a string of concatenated 75-ps delay > > elements, held constant by a 200 MHz oscillator that controls the > > delay stable through Vcc adjustments. > > You can even modulate this delay by 10% up and down. > > Teaching is addictive... > > Peter A. > > Hi Peter, > > You said that Virtex-4 IDELAY element is stable over temperature, > voltage and processing. Is it stable over continuous years of > operation too? > In our project we are currently using IDELAY to adjust optimal > sampling points in LVDS buses between two Virtex-4 devices (-11 grade) > @ 700 Mbps. > We want to know if PCB's issues like capacitance and humidity > variations would be more critical than FPGA deviations along > continuous years of operation. > > Thanks, > Selensky Sorry, I misunderstood your question. You are asking whether the pc-board delay may change too much over time. My gut feel is that humidity has very little impact on the propagation time, which is affected by the square root of C, so its impact would also be fairly benign. PeterArticle: 135614
Our little Drigmorn1 board is gain some popularity amongst students. Some details here http://www.enterpoint.co.uk/component_replacements/drigmo= rn1.html. John Adair Enterpoint. On 8 Oct, 13:03, "Bar Nash" <waves...@netvision.net.il> wrote: > Hi all > > I want to buy a FPGA experimantal =A0board for getting into this area as = a > designer. > > Which boards are popular among EDA students ? > > Which board you can recomand from your experince when you were new at FPG= A > area ? > > Thanks > ECArticle: 135615
andrea.cortis@gmail.com wrote: > A demo is exactly what I am looking for: a demonstration of how to > make a simple program that takes two variables in input (say a and b) > from the pc, calculates their sum c=a+b on the FPGA, and finally > passes the variable c to the pc for further computations. > The Spartan board I have does have a rs232 interface. Does anybody > know of such a demo for my board? Many thanks again. A bit outdated (I would write the RS232 part differently today), but should still work: http://www.frank-buss.de/vhdl/spartan3e.html -- Frank Buss, fb@frank-buss.de http://www.frank-buss.de, http://www.it4-systems.deArticle: 135616
On Oct 8, 12:49 pm, "Teece" <tom_cip_11...@yahoo.com> wrote: > Hi, > > I have been writing Verilog code for many years but the time has come for me > to learn VHDL. Please recommend either a book or web reference or learning > VHDL that would be good for someone that is experienced in FPGA architecture > and Verilog. > > Thank You > Tom > tom_cip_11...@hotmail.com Another good book is "The Designer's Guide to VHDL" by Peter Ashenden. cheers, Stephen F# to FPGAs Avalda Corp. http://www.avalda.comArticle: 135617
Hello : I have been designing for FPGA's for a number of years and have completed a number of real-time control / signal processing / communication systems in Altera devices (up to about 100K LE's) all using schematic capture and Megawizard functions. I have had a quick try with VHDL on a couple of occasions, but just didn't get along with it - I also write a great deal of C/C++ code and design hardware (FPGA, DSP, Power Electronics) and found that I kept putting my software hat on whenever I use a text editor....getting old you see. Now I need to get up to speed on VHDL - implementing serial link protocols, finite state machines and such stuff as a schematic just isn't that smart, and I think the synthesis would be better with some form of HDL source. Can anybody recommend some classroom type training suitable for somebody who really doesn't need an introduction to FPGA's and digital design stuff, just VHDL ? I am thinking about this : http://www.trainingcity.com/course_outline_detail.asp?CourseID=3100 Anybody have experience with this course or this company ? Any suggestions would be appreciated. GaryArticle: 135618
On 2008-10-09, Uwe Bonnes <bon@elektron.ikp.physik.tu-darmstadt.de> wrote: > Do I miss some settings? > Do I missinterpret something? Personally I've never had much luck relying on the timing figures from XST. I've seen both significant underestimates and overestimates from XST. For example, right now I'm looking at a design where XST gives an estimate of 262 MHz whereas trce tells me that the design will run at 340 MHz... I would take a look at the failing design in either the floorplanner or the FPGA editor to figure out if something very weird is going on with the critical paths. /Andreas PS: For your amusement I offer up the following specimen of a weird floorplan I once encountered a couple of years ago: http://www.da.isy.liu.se/~ehliar/weird_floorplan.pngArticle: 135619
On Oct 10, 12:11=A0am, FreeWheel <grinder...@gmail.com> wrote: > Hi everybody, > > First off all...sorry for cross posting this to both arch.fpga and > arch.embedded, but I think it fits in both places. > > I'm currently in the selection fase of an FPGA vendor. we need a >2M > gate chip with DSP capabilities, SERDES and offcourse the mandatory > low cost. Likewise we need a high performance embedded CPU softcore > for system management. At the moment things are pointing towards > lattice because of price, availability and HW specs. As i'm involved > in the SW part of the design me and my team has been trying to > evaluate the tool chain (ispLEVER + Eclipse Mico32 environment) and > the evaluation board bassed on a Lattice ECP2 FPGA. But we're not > quite happy about it. We have spend allot of time to get a very simple > CPU system (CPU + intern memory) running on the FPGA. We have done > progress but this is very slow and we seem to keep banging our heads > against the wall when we try expand the system. My conclusions on the > Lattice tool chain and the Mico32 system based on the evaluation is as > follows: > > * Bad documentation on both tools and eval boards. Some stuff will > never work if you don't reverse engineer HW or get correct support. > * Outdated tutorials regarding to tool and HW revisions. > * Poorly integrated and bugy tools. > * Extremely slow JTAG connection to the CPU (19kbit/sec) for SW > debugging/downloading. > * Hard to trouple shot the CPU configuration (e.g. SW debugger cannot > connect to the CPU). > * Tools crashes > * Overall poorly matured product (Mico32 and tools). > > So my questions are: > > * Is it only me that have come to this conclusion? Are some of you > using lattice and Mico32 with success in a commercial product? > * Any ways (known fixes to issues, third party stuff etc.) to get > faster to market with the Lattice solution? > * Is the stuff (NIOS II and tools) from Altera (or any other vendor) > any better regarding the complaints above? > * The Mico32 is open source but is the origin of the code made by > Lattice themselves or? > * Any recommendations or experiences to share? > > Hope to see some comments on my conclusions and questions. > > Thank you! > > Best Regards > -- > MMJ > > PS: All in this message is my personal opinions - and may not be the > ones of my employer. I dont have much of experience with Lattice, but I have used Altera NIOS and Xilinx MicroBlaze. And in general I have also found the tool flow to be very complicated, It takes lot of time to get basic things work, until the time you get used to the tool and also to the tool documentation and the version incompatibilities. I for example had a tough time getting flash up with Microblaze, which should have been a simple task. But then the good thing about this configurable processors is that once you put all the effort and get things up, you really get a powerful reconfigurable system. You could change the system to have one more serial port, or add extra I2C Controller and so on. I have come across number of people who are using Microblaze as their control processor for their product. Cheers. GoliArticle: 135620
"Gary Pace" <abc@xyz.com> wrote in message news:_uqdnVHyM7bGPnPVnZ2dnUVZ_tXinZ2d@comcast.com... > Hello : > > I have been designing for FPGA's for a number of years and have completed > a number of real-time control / signal processing / communication systems > in Altera devices (up to about 100K LE's) all using schematic capture and > Megawizard functions. > > I have had a quick try with VHDL on a couple of occasions, but just didn't > get along with it - I also write a great deal of C/C++ code and design > hardware (FPGA, DSP, Power Electronics) and found that I kept putting my > software hat on whenever I use a text editor....getting old you see. > > Now I need to get up to speed on VHDL - implementing serial link > protocols, finite state machines and such stuff as a schematic just isn't > that smart, and I think the synthesis would be better with some form of > HDL source. > > Can anybody recommend some classroom type training suitable for somebody > who really doesn't need an introduction to FPGA's and digital design > stuff, just VHDL ? > > I am thinking about this : > http://www.trainingcity.com/course_outline_detail.asp?CourseID=3100 > > Anybody have experience with this course or this company ? > > Any suggestions would be appreciated. > > Gary > I would check out Jim Lewis' advance VHDL course at http://www.synthworks.com/ Although I did not attend this course, I know that Jim is a VHDL guru and he is one of the main drivers behind the VHDL-2008 standard. He wrote some interesting papers on how to do advance verification (Transaction Level Modelling, Constraint Random etc) using VHDL. Another course to check out is the advance VHDL course from Doulos. http://www.doulos.com/content/training/advanced_vhdl_training.php Not sure about the US but in Europe they are the market leader. I have enjoyed many of their courses and they are exceptionally good. Hans www.ht-lab.comArticle: 135621
>> host_data <= host_data_out when host_dout_en = '1' else "ZZ....ZZZZ"; >> > Hi > I have no experience with Actel but I may have a clue. > host_dout_en is a single bit register, whereas host_data_out is a vector. If the tool isn't smart > enough to replicate the enable register it won't be possible to put it in an IOB. > Try to define your enable as a vector and use a for...generate loop to control each individual bit > of your output vector. WHAT >:-0 That's the way I've been describing bus tri-states since I started FPGA design 15 odd years ago. As far as I know it's a 'standard' so the tools should be able to deal with it. NialArticle: 135622
"Frank Buss" <fb@frank-buss.de> wrote in message news:bk5rk2omzbbs$.6ltaeouy3nwp.dlg@40tude.net... > FreeWheel wrote: > >> * Is the stuff (NIOS II and tools) from Altera (or any other vendor) >> any better regarding the complaints above? > > There are cheap evaluation kits with NIOS II integrated available, so > maybe > you should try it yourself. I've used it for a commercial product with a > Cyclone, but I wouldn't do it again. It is possible and there are some > nice > IPs, but the price of a FPGA with all the IPs you'll need for a good > system > (CPU core, SDRAM/network/UART etc.) is higher than buying it in a > hardwired > microcontroller, like one of this ones, if you don't need already big > parts > of the FPGA for FPGA related things, and the NIOS II would be just a small > offset to the whole system. > > http://www.st.com/inchtml-pages-stm32.html > http://www.standardics.nxp.com/microcontrollers/ (the LPC series is nice) > http://www.atmel.com/products/at91/ > > And using NIOS II is sometimes tricky (see > http://forum.niosforum.com/forum/index.php?showforum=2 for some > interesting > forum posts). Things which are easy with hardwired microcontrollers > sometimes gets difficult with NIOS. There were even CPU core bugs in older > versions of NIOS and the development environment is bloated and slow. The > SoPC builder is powerful, but it is complicated to configure the system > (sometimes you have to configure some special attributes of a component > and > failing to do so results in strange compiling errors), the right busses, > arbitraters etc. and route it to a working system. > > In theory I like the idea of using just one FPGA to build your whole > system, but I think a micorcontroller is better: No costs for additional > IPs, DSP functions in the bigger ones included, all hardware you'll need > included in tested hardwired blocks, if you choose the right one and free > tools like GCC for fast ARM CPUs etc. makes live much easier. Use an > additional FPGA for the parts which needs a FPGA, e.g. routing many fast > signals, additional DSP functions etc. and attach it to the > microcontroller > with a memory mapped interface for more complex systems, or a simpler > interface. > > -- > Frank Buss, fb@frank-buss.de > http://www.frank-buss.de, http://www.it4-systems.de I think I'm with Frank on this one - unless there is a compelling reason to use an FPGA based micro I think you have a much easier development route with a stand alone device. With a typical ARM based processor or micro-controller you get completely sorted and integrated IP for the core, memory, on chip flash, serial IO, etc etc AND a choice of development tools and decent hardware supported debugging tools. You need to factor in a massive increase in development cost if you go the all FPGA route - there will be the odd occasion when this pays off but with the cost of a decent stand alone processor at << $10 you will need to be building huge numbers of systems. For me (typical build numbers for FPGA based designs <50) it has never looked a good route. Michael KellettArticle: 135623
On 2008-10-10, Uwe Bonnes <bon@elektron.ikp.physik.tu-darmstadt.de> wrote: > It makes a difference if XST overestimates delays and trce is better. That > way, you get an early warning. As I mentioned, I've seen both under and overestimates. The output from XST in regards to performance should probably only be used as a very rough estimate. > The net delays in my example seem very high. E.g. the read data from a > blockram is distributed to 7 sinks (2 * MULT18X18, 3 adder/subtractors, 1 > MUX and another BRAM) and in the critical path it takes 1.7 ns for the net > to deliver the BRAM data, according to trce. Have you looked at the FPGA editor or floorplanner to see how the blockram and multiplier have been placed? Perhaps you could improve timing by making sure that they are placed as close to each other as possible? If that doesn't work, take a look at the critical path in the FPGA editor to see if the routing from the blockram to the multiplier is looking optimal or not. If it is optimal or close to optimal there is really not much to do besides adding pipeline registers :/ /AndreasArticle: 135624
Andreas Ehliar <ehliar-nospam@isy.liu.se> wrote: > On 2008-10-09, Uwe Bonnes <bon@elektron.ikp.physik.tu-darmstadt.de> wrote: > > Do I miss some settings? > > Do I missinterpret something? > Personally I've never had much luck relying on the timing figures from > XST. I've seen both significant underestimates and overestimates from XST. > For example, right now I'm looking at a design where XST gives an estimate > of 262 MHz whereas trce tells me that the design will run at 340 MHz... > I would take a look at the failing design in either the floorplanner or > the FPGA editor to figure out if something very weird is going on with the > critical paths. It makes a difference if XST overestimates delays and trce is better. That way, you get an early warning. The net delays in my example seem very high. E.g. the read data from a blockram is distributed to 7 sinks (2 * MULT18X18, 3 adder/subtractors, 1 MUX and another BRAM) and in the critical path it takes 1.7 ns for the net to deliver the BRAM data, according to trce. -- Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------
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