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
Enterpoint is moving it's design and sales team to a new location next Tuesday. Expect our telephone and email service not to be up to the usual standard for about 1 week after the move. Our website and web shop will be unaffected by the move but shipping of items bought on the web shop may take an extra day to ship over normal service. Longer term the move will enable a better service from Enterpoint. We have been seriously space constrainted over the last year and some of our bigger product plans can now be unleashed. John Adair Enterpoint Ltd.Article: 147001
On Apr 7, 6:50=A0pm, Yan <yan.li...@gmail.com> wrote: > On Mar 31, 10:04=A0am, Ed McGettigan <ed.mcgetti...@xilinx.com> wrote: > > > > > > > On Mar 31, 1:51=A0am, luudee <rudolf.usselm...@gmail.com> wrote: > > > > Does anybody else, besides xilinx, make FMC boards for ml605 & sp605 = ? > > > > HW-FMC-XM105-G =A0FMC XM105 DEBUG CARD > > > HW-FMC-XM104-G =A0FMC CONNECTIVITY MEZZANINE CARD > > > > Buying Xilinx products now means going through Avnet, which is a > > > nightmare and HUGE lead times ... > > > > Thanks, > > > rudi > > > While the XM104 is listed with a 8 week lead time on the Avnet site, I > > know that we have these available in inventory and they will ship > > promptly after the order is placed. =A0The XM105 is listed with a 2 wee= k > > lead time. > > > There are a number of other companies releasing FMC cards, just be > > sure that the cards support a VADJ of 2.5V and there shouldn't be a > > problem. > > > 4DSP recently announced a FMC familyhttp://www.przoom.com/news/66794/ > > > Curtiss-Wright also has a number of boards.http://www.cwcembedded.com/0= /62/651.html > > > And Xilinx has a number of other boards in pipeline to be released > > next quarter.http://www.xilinx.com/fmc > > > Ed McGettigan > > -- > > Xilinx Inc. > > Ed, > > I just board a ML605 kit and is shopping FMC daughter board. I > understand that Xilinx worked with Analog Device on a multi-mode radio > demo platform. Analog Devices provided a RF board called Mixed Signal > Digital Pre-Distortion (MSDPD) board. I wonder if that board is > available for purchase. I got the information from: > > http://www.xilinx.com/publications/prod_mktg/Radio-TDP-SellSheet.pdf > > Yan- Hide quoted text - > > - Show quoted text - This FMC board was developed by Analog Devices and while I had some involvement in the initial design phase I'm not sure what the go-to- market strategy was for the board. I would suggest that you use the "Contact Wireless" team link on this page to get further information on availability. http://www.xilinx.com/esp/wireless.htm Ed McGettigan -- Xilinx Inc.Article: 147002
On Apr 8, 11:57=A0pm, Speed <speedboy1...@gmail.com> wrote: > Dear All, > =A0 We are planning to design a board with four FPGAs to emulate X86 > CPU. The FPGA=92s JTAG ports are serially chained together. My problem > is that whether the Xilinx=92s ChipScope can support debugging multiple > FPGAs via a single JTAG chain at the same time? So we can set > different trigger conditions to different FPGA chips at the same time > and watch the sampled data from ChipScope. > > Thanks in advance, > Speed. Yes, ChipScope can handle debugging in multiple FPGAs in the same chain. Each of the ILA cores will be independent of each other. Ed McGettigan -- Xilinx Inc.Article: 147003
Does the Spartan-6 LX family or Spartan3A support the Multipoint-LVDS specifications? We need input and ouput buffers compliant to M-LVDS type1 and types 2. Also , the buffers should be 5V LVTTL tolerant.Article: 147004
Our PCB guy saying there's no enough room for Vccint pins (all converge at center of the chip) so that each pin has one 0.01 uF decoupling cap. As a result we have just 12 caps for 23 vccint pins !!! Wonder if anyone out there has similar pcb placement problem like us, and how you solve it ? TIAArticle: 147005
I think I have about had it with VHDL. I've been using the numeric_std library and eventually learned how to get around the issues created by strong typing although it can be very arcane at times. I have read about a few suggestions people are making to help with some aspects of the language, like a selection operator like Verilog has. But it just seems like I am always fighting some aspect of the VHDL language. I guess part of my frustration is that I have yet to see where strong typing has made a real difference in my work... at least an improvement. My customer uses Verilog and has mentioned several times how he had tried using VHDL and found it too arcane to bother with. He works on a much more practical level than I often do and it seems to work well for him. One of my goals over the summer is to teach myself Verilog so that I can use it as well as I currently use VHDL. Then I can make a fully informed decision about which I will continue to use. I'd appreciate pointers on good references, web or printed. Without starting a major argument, anyone care to share their feelings on the differences in the two languages? RickArticle: 147006
I seem to be stuck on this one. I have 2 DCMS creating a 100MHz clock and a 125MHz clock derived from a common 25MHz clock. Signals cross clock domains using grey-code and suitable multiple latches where appropriate. I am aware of metastable states etc and their consequences.. However when I specify a 40ns timing criteria for the 25MHz clock I get a mapping failure. I increase the timing criteria to 80ns and the timing analysis is expecting clock transitions at 16 and 20ns, for signals crossing clock domains which of course it fails. How can I turn off timing analysis for signals crossing clock domains? I note that the "TIG" can't be used for "from" "to" statements.Article: 147007
On Apr 9, 9:05=A0am, Mawa_fugo <cco...@netscape.net> wrote: > Our PCB guy saying there's no enough room for Vccint pins (all > converge at center of the chip) so that each pin has one 0.01 uF > decoupling cap. =A0As a result we have just 12 caps for 23 vccint > pins !!! > > Wonder if anyone out there has similar pcb placement problem like us, > and how you solve it ? > > TIA btw, those caps are in 402 package,Article: 147008
Before the fixed and floating point packages came out, I would have said there is little difference regarding RTL capabilities between Verilog and VHDL. But those two packages revealed a fundamental strength of VHDL that simply does not exist in verilog. By simply writing a new package, a whole new capability was created that would take a substantial language change in Verilog. Yes, the as-released packages took advantage of features only available in a related change in the language itself, but the "compatibility" packages ably demonstrate that the working concept is viable even within the confines the original language, thus demonstrating the true strengh of the basic language of VHDL. Not that the fixed/floating point packages are nirvana, but they do represent a huge step in the right direction. If we only had assignment operator overloading in VHDL, it would be much closer... Still, that's a capability much closer to reality in VHDL than in Verilog. Sure, verilog has many "built-in" tricks, but they are only applicable to the existing type structure, and cannot be expanded upon without revising the language itself. Even before the fixed/floating point packages, integers simply work in VHDL (within the range limitations), whereas in Verilog, they don't always, but they also don't complain when they don't work either. In general, strong typing and built-in bounds checking in VHDL catch more problems, closer to the source of the problems, with no additional code being written, than is possible in Verilog without having to write A LOT of extra code. It seems for almost every weak- typing-enabled shortcut in verilog, there is also a hidden, often silent, "gotcha" to go along with it. AndyArticle: 147009
f, This is your lucky day: Go read my new blog post: http://forums.xilinx.com/t5/PLD-Blog/Timing-Constraints-Part-4-of-5/ba-p/66696 where TIG is discussed, and an example given how it can be used in a FROM-TO. Since this design is completely synchronous to the 25 MHz clock, if properly constrained (and designed) there will be metastability issues at all. Your Gray code and synchronizers may not be necessary at all. However, if you don't have the time (or knowledge) to do this properly, then having a two clocks that are almost (but not quite) synchronous can be a nightmare, and no amount of Gary coded counters, nor synchronizers will save you: you will be "almost always at the wrong point" so frequently that you have created the perfect storm for looking at metastable events. The built in BRAM FIFO in V5 and V6 is the obvious solution to cross boundaries, or the use of a FIFO from the core generator, is suggested: do not try to spin your own solution unless you are an expert in clock domain crossing -- this is not for "newbies" to try (unless they are trying to develop the skills to do it right). You would be better off using the 125 MHz clock domain everywhere, and creating a clock enable that disables one 125 clock out of every five 125 clocks (for the 100 MHz domain processing). Then you will have no need to cross any clock boundaries, the design is simpler, more robust, and will likely just work. If you then need to transfer data out at 100 MHz, that is where the FIFO is best used: once, at this boundary. The same is not true for transferring 100 MHz data into the 125 MHz domain, that is accomplished by just sampling at the right time (the four clocks not dropped every 5). AustinArticle: 147010
On 4/9/2010 3:26 PM, Mawa_fugo wrote: > On Apr 9, 9:05 am, Mawa_fugo<cco...@netscape.net> wrote: >> Our PCB guy saying there's no enough room for Vccint pins (all >> converge at center of the chip) so that each pin has one 0.01 uF >> decoupling cap. As a result we have just 12 caps for 23 vccint >> pins !!! >> >> Wonder if anyone out there has similar pcb placement problem like us, >> and how you solve it ? >> >> TIA > > btw, those caps are in 402 package, Fit them on the backside from the FPGA. Use round pads on the 0402 caps so they fit in between the via array. Better still, ignore Xilinx's ridiculously conservative recommendations and design it properly. http://www.x2y.com/bypass/mount/backside_cap.pdf HTH, Syms.Article: 147011
a, If it is not in the data sheet, then it isn't supported. I have no idea what "multi-point" LVDS is: sounds like someone's idea of how to ruin a perfectly good point to point IEEE standard! OK, I just read about it on Wikipedia, and that confirms my suspicions ... There is the "bus-LVDS" which we 'invented' and supported, but the signal integrity of that is a compromise at best, and I have never really liked to deal with it at all. Regardless, it does work (within its limits). For 5v tolerance, I suggest level shifters, or using resistors. At these advanced technology nodes we are lucky to be able to still use 3.3v IO! AustinArticle: 147012
Hello everybody,
long time no see. ;-)
Now that I return to FPGA design at least for hobby purposes, I have
some trouble with data2mem. Iam using Webpack 11.1. I want to use
Picoblaze in a Spartan 3A 700. For updating of the program memory I
use data2mem, but without success. :-(
Here is my bmm file
ADDRESS_SPACE ROM_SPACE RAMB16 [0x0000:0x09FF]
BUS_BLOCK
bram0 [15:0] LOC =X0Y0;
END_BUS_BLOCK;
END_ADDRESS_SPACE;
here my command line for data2mem
data2mem -i -bm ..\pico.bmm -bd pico_bas.mem -bt ..\top_picoblaze.bit -
ob ..\top_picoblaze_prog.bit
When I do so, I get the following error message
ERROR:Data2MEM:29 - Inconsistent address space size in ADDRESS_SPACE
'ROM_SPACE'.
ADDRESS_SPACE was defined as 0x00000A00 bytes, but the
ADDRESS_RANGE total is 0x00000800 bytes.
When I change the definition in the BMM file to
ADDRESS_SPACE ROM_SPACE RAMB16 [0x0000:0x07FF]
BUS_BLOCK
bram0 [15:0] LOC =X0Y0;
END_BUS_BLOCK;
END_ADDRESS_SPACE;
I get this error.
ERROR:Data2MEM:31 - Out of bounds code segment for ram space in '..
\pico.bmm'.
Memory space 'ROM_SPACE' occupies [0x00000000:0x000007FF]
Code segment #0 occupies [0x00000000:0x000009FF]
The documentation of data2mem is sometimes confusing. At one place it
says there is only RAMB16 for Spartan 3, at another line it says
RAMB18 is available for Spartan 3.
Also using RAMB18 does not work.
ADDRESS_SPACE ROM_SPACE RAMB18 [0x0000:0x07FF]
BUS_BLOCK
bram0 [17:0] LOC =X0Y0;
END_BUS_BLOCK;
END_ADDRESS_SPACE;
ERROR:Data2MEM:29 - Inconsistent address space size in ADDRESS_SPACE
'ROM_SPACE'.
ADDRESS_SPACE was defined as 0x00000800 bytes, but the
ADDRESS_RANGE total is 0x00000900 bytes.
Any hint is appreciated.
Regards
Falk
Article: 147013It's basically impossible to do on a cost effective board. In practise you can get away with a lot less of them if you planes are done well and paired properly with a ground plane. Array capacitors we also use a lot for density and you can see those on all of our development boards for Spartan-3 etc. John Adair Enterpoint Ltd. On 9 Apr, 15:05, Mawa_fugo <cco...@netscape.net> wrote: > Our PCB guy saying there's no enough room for Vccint pins (all > converge at center of the chip) so that each pin has one 0.01 uF > decoupling cap. =A0As a result we have just 12 caps for 23 vccint > pins !!! > > Wonder if anyone out there has similar pcb placement problem like us, > and how you solve it ? > > TIAArticle: 147014
"austin" <austin@xilinx.com> wrote in message news:fc92c4bb-3a00-4990-b2f5-3767c15c41c9@x20g2000yqb.googlegroups.com... > f, > > This is your lucky day: > > Go read my new blog post: > > http://forums.xilinx.com/t5/PLD-Blog/Timing-Constraints-Part-4-of-5/ba-p/66696 > > where TIG is discussed, and an example given how it can be used in a > FROM-TO. > > Since this design is completely synchronous to the 25 MHz clock, if > properly constrained (and designed) there will be metastability issues > at all. > > Your Gray code and synchronizers may not be necessary at all. > However, if you don't have the time (or knowledge) to do this > properly, then having a two clocks that are almost (but not quite) > synchronous can be a nightmare, and no amount of Gary coded counters, > nor synchronizers will save you: you will be "almost always at the > wrong point" so frequently that you have created the perfect storm for > looking at metastable events. > > The built in BRAM FIFO in V5 and V6 is the obvious solution to cross > boundaries, or the use of a FIFO from the core generator, is > suggested: do not try to spin your own solution unless you are an > expert in clock domain crossing -- this is not for "newbies" to try > (unless they are trying to develop the skills to do it right). > > You would be better off using the 125 MHz clock domain everywhere, and > creating a clock enable that disables one 125 clock out of every five > 125 clocks (for the 100 MHz domain processing). Then you will have no > need to cross any clock boundaries, the design is simpler, more > robust, and will likely just work. > > If you then need to transfer data out at 100 MHz, that is where the > FIFO is best used: once, at this boundary. The same is not true for > transferring 100 MHz data into the 125 MHz domain, that is > accomplished by just sampling at the right time (the four clocks not > dropped every 5). > > Austin Many thanks, I had made a syntax error where I wrote TIMESPEC "my_fromto" = FROM "my_from_grp" TO "my_to_grp" TIG; and when changed ito TIMESPEC TS_my_fromto = FROM "my_from_grp" TO "my_to_grp" TIG; it all worked. I'm sure in my past designs I haven't had this problem, but I guess using clocks which have a common sourse means that the timing analyser has founf something to analyse! I take your point about the sourcing of clocks. For various reasons I want the design to be flexible as possible, and willing to accept the consequences. Also missing a clock every 5 will require a tighter design in terms of timing.Article: 147015
On Apr 9, 10:23=A0am, John Adair <g...@enterpoint.co.uk> wrote: > It's basically impossible to do on a cost effective board. In practise > you can get away with a lot less of them if you planes are done well > and paired properly with a ground plane. Array capacitors we also use > a lot for density and you can see those on all of our development > boards for Spartan-3 etc. > > John Adair > Enterpoint Ltd. > > On 9 Apr, 15:05, Mawa_fugo <cco...@netscape.net> wrote: > > > Our PCB guy saying there's no enough room for Vccint pins (all > > converge at center of the chip) so that each pin has one 0.01 uF > > decoupling cap. =A0As a result we have just 12 caps for 23 vccint > > pins !!! > > > Wonder if anyone out there has similar pcb placement problem like us, > > and how you solve it ? > > > TIA > > I found this ug454, about the development board using the same part http://www.xilinx.com/support/documentation/boards_and_kits/ug454_sp3a_dsp_= start_ug.pdf Page 56 they're talking about the ladder caps for Vccint 1.2V, there're 13 caps of 0.01 and several other values, makes up total of 25 caps. There's no footprint image for them !! I guess, just the 13 high speed caps are placed on the back of the chip, right at the via - impossible to place bigger caps in that area Wonder if someone has the image of the bottom of this board ? TIAArticle: 147016
On Apr 9, 10:08=A0am, Falk Brunner <falk.brun...@gmx.de> wrote: > Hello everybody, > > long time no see. ;-) > > Now that I return to FPGA design at least for hobby purposes, I have > some trouble with data2mem. Iam using Webpack 11.1. I want to use > Picoblaze in a Spartan 3A 700. For updating of the program memory I > use data2mem, but without success. :-( > > Here is my bmm file > > ADDRESS_SPACE ROM_SPACE RAMB16 [0x0000:0x09FF] > =A0 =A0 =A0 =A0 BUS_BLOCK > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 bram0 [15:0] LOC =3DX0Y0; > =A0 =A0 =A0 =A0 END_BUS_BLOCK; > END_ADDRESS_SPACE; > > here my command line for data2mem > > data2mem -i -bm ..\pico.bmm -bd pico_bas.mem -bt ..\top_picoblaze.bit - > ob ..\top_picoblaze_prog.bit > > When I do so, I get the following error message > > ERROR:Data2MEM:29 - Inconsistent address space size in ADDRESS_SPACE > 'ROM_SPACE'. > =A0 =A0 ADDRESS_SPACE was defined as 0x00000A00 bytes, but the > ADDRESS_RANGE total is 0x00000800 bytes. > > When I change the definition in the BMM file to > > ADDRESS_SPACE ROM_SPACE RAMB16 [0x0000:0x07FF] > =A0 =A0 =A0 =A0 BUS_BLOCK > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 bram0 [15:0] LOC =3DX0Y0; > =A0 =A0 =A0 =A0 END_BUS_BLOCK; > END_ADDRESS_SPACE; > > I get this error. > > ERROR:Data2MEM:31 - Out of bounds code segment for ram space in '.. > \pico.bmm'. > =A0 =A0 Memory space 'ROM_SPACE' occupies [0x00000000:0x000007FF] > =A0 =A0 Code segment #0 occupies [0x00000000:0x000009FF] > > The documentation of data2mem is sometimes confusing. At one place it > says there is only RAMB16 for Spartan 3, at another line it says > RAMB18 is available for Spartan 3. > > Also using RAMB18 does not work. > > ADDRESS_SPACE ROM_SPACE RAMB18 [0x0000:0x07FF] > =A0 =A0 =A0 =A0 BUS_BLOCK > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 bram0 [17:0] LOC =3DX0Y0; > =A0 =A0 =A0 =A0 END_BUS_BLOCK; > END_ADDRESS_SPACE; > > ERROR:Data2MEM:29 - Inconsistent address space size in ADDRESS_SPACE > 'ROM_SPACE'. > > =A0 =A0 ADDRESS_SPACE was defined as 0x00000800 bytes, but the > ADDRESS_RANGE total is 0x00000900 bytes. > > Any hint is appreciated. > > Regards > Falk You didn't show your mem file, but if it starts at, e.g. 0x200, and is 0x800 long, that could explain that sort of error. You would fix that by using a space like [0x200:0x9FF]. Regards, PatArticle: 147017
On Apr 9, 9:07=A0am, rickman <gnu...@gmail.com> wrote: > I think I have about had it with VHDL. =A0I've been using the > numeric_std library and eventually learned how to get around the > issues created by strong typing although it can be very arcane at > times. =A0I have read about a few suggestions people are making to help > with some aspects of the language, like a selection operator like > Verilog has. =A0But it just seems like I am always fighting some aspect > of the VHDL language. > > I guess part of my frustration is that I have yet to see where strong > typing has made a real difference in my work... at least an > improvement. =A0My customer uses Verilog and has mentioned several times > how he had tried using VHDL and found it too arcane to bother with. > He works on a much more practical level than I often do and it seems > to work well for him. > > One of my goals over the summer is to teach myself Verilog so that I > can use it as well as I currently use VHDL. =A0Then I can make a fully > informed decision about which I will continue to use. =A0I'd appreciate > pointers on good references, web or printed. > > Without starting a major argument, anyone care to share their feelings > on the differences in the two languages? > > Rick The best online references are the Sutherland Verilog references. There is an online HTML reference for Verilog 95 (excellent), and a PDF for Verilog 2001 (good): http://www.sutherland-hdl.com/online_verilog_ref_guide/vlog_ref_top.html http://sutherland-hdl.com/online_verilog_ref_guide/verilog_2001_ref_guide.p= df Cliff Cummings has a lot of good papers on Verilog at his site: http://sunburst-design.com/papers/ In particular, if you read and carefully grok his paper about non- blocking vs. blocking assignments, you will be well on your way to being a Verilog wizard: http://sunburst-design.com/papers/CummingsSNUG2000SJ_NBA.pdf Regards, PatArticle: 147018
> Also , the buffers should be 5V LVTTL tolerant. Which? 5V, or LVTTL? They are two different things. IIRC, Spartan-6 does support LVTTL. It does not support 5V I/O directly.Article: 147019
On 9 Apr., 18:39, Patrick Maupin <pmau...@gmail.com> wrote: > You didn't show your mem file, but if it starts at, e.g. 0x200, and is > 0x800 long, that could explain that sort of error. =A0You would fix that > by using a space like [0x200:0x9FF]. Its pretty simple, it starts with @00000000, followed by 1024 lines of five digit hex numbers, representing the 18 Bit Opcodes of Picoblaze. Regards FalkArticle: 147020
On Apr 9, 12:43=A0pm, Falk Brunner <falk.brun...@gmx.de> wrote: > On 9 Apr., 18:39, Patrick Maupin <pmau...@gmail.com> wrote: > > > You didn't show your mem file, but if it starts at, e.g. 0x200, and is > > 0x800 long, that could explain that sort of error. =A0You would fix tha= t > > by using a space like [0x200:0x9FF]. > > Its pretty simple, it starts with @00000000, followed by 1024 lines of > five digit hex numbers, representing the 18 Bit Opcodes of Picoblaze. > > Regards > Falk Well, in that case, it's 17:0, not 15:0, for the width, no? Regards, PatArticle: 147021
On Apr 9, 12:55=A0pm, Patrick Maupin <pmau...@gmail.com> wrote: > On Apr 9, 12:43=A0pm, Falk Brunner <falk.brun...@gmx.de> wrote: > > > On 9 Apr., 18:39, Patrick Maupin <pmau...@gmail.com> wrote: > > > > You didn't show your mem file, but if it starts at, e.g. 0x200, and i= s > > > 0x800 long, that could explain that sort of error. =A0You would fix t= hat > > > by using a space like [0x200:0x9FF]. > > > Its pretty simple, it starts with @00000000, followed by 1024 lines of > > five digit hex numbers, representing the 18 Bit Opcodes of Picoblaze. > > > Regards > > Falk > > Well, in that case, it's 17:0, not 15:0, for the width, no? > > Regards, > Pat Oh, I see what you mean. I've never used the parity bits, so I don't know how that works.Article: 147022
On Apr 9, 11:45=A0am, "Fredxx" <fre...@spam.com> wrote: > "austin" <aus...@xilinx.com> wrote in message > > news:fc92c4bb-3a00-4990-b2f5-3767c15c41c9@x20g2000yqb.googlegroups.com... > > > > > f, > > > This is your lucky day: > > > Go read my new blog post: > > >http://forums.xilinx.com/t5/PLD-Blog/Timing-Constraints-Part-4-of-5/b... > > > where TIG is discussed, and an example given how it can be used in a > > FROM-TO. > > > Since this design is completely synchronous to the 25 MHz clock, if > > properly constrained (and designed) there will be metastability issues > > at all. > > > Your Gray code and synchronizers may not be necessary at all. > > However, if you don't have the time (or knowledge) to do this > > properly, then having a two clocks that are almost (but not quite) > > synchronous can be a nightmare, and no amount of Gary coded counters, > > nor synchronizers will save you: =A0you will be "almost always at the > > wrong point" so frequently that you have created the perfect storm for > > looking at metastable events. > > > The built in BRAM FIFO in V5 and V6 is the obvious solution to cross > > boundaries, or the use of a FIFO from the core generator, is > > suggested: =A0do not try to spin your own solution unless you are an > > expert in clock domain crossing -- this is not for "newbies" to try > > (unless they are trying to develop the skills to do it right). > > > You would be better off using the 125 MHz clock domain everywhere, and > > creating a clock enable that disables one 125 clock out of every five > > 125 clocks (for the 100 MHz domain processing). =A0Then you will have n= o > > need to cross any clock boundaries, the design is simpler, more > > robust, and will likely just work. > > > If you then need to transfer data out at 100 MHz, that is where the > > FIFO is best used: =A0once, at this boundary. =A0The same is not true f= or > > transferring 100 MHz data into the 125 MHz domain, that is > > accomplished by just sampling at the right time (the four clocks not > > dropped every 5). > > > Austin > > Many thanks, I had made a syntax error where I wrote > > TIMESPEC "my_fromto" =3D FROM "my_from_grp" TO "my_to_grp" TIG; > > and when changed ito > > TIMESPEC TS_my_fromto =3D FROM "my_from_grp" TO "my_to_grp" TIG; > > it all worked. > > I'm sure in my past designs I haven't had this problem, but I guess using > clocks which have a common sourse means that the timing analyser has foun= f > something to analyse! > > I take your point about the sourcing of clocks. =A0For various reasons I = want > the design to be flexible as possible, and willing to accept the > consequences. =A0Also missing a clock every 5 will require a tighter desi= gn in > terms of timing. It always bothered me that time specs needed to start with "TS". This is the syntax problem in the first version, not the quotes.Article: 147023
Argrr, I have a STRANGE feeling.
Since I use the RAM in 18 Bits width, every data word ist 5 hex digits
long, which is 2.25 bytes. Times 1024 equals 2304 Bytes, which is
0x900.
I guess data2mem is confused by the 18 bit data width . . .
It calculates the number of nibbles instead the number of 18 bit
words.
ADDRESS_SPACE was defined as 0x00000800 bytes, but the
ADDRESS_RANGE total is 0x00000900 bytes.
0x800 = 2048 Words with 16 Bits each
0x900 = 2304 = 2048 + 256 Words with 18 Bits each
Looks like another ISE bug . . . :-(
Article: 147024On Apr 9, 10:07=A0am, rickman <gnu...@gmail.com> wrote: > I think I have about had it with VHDL. =A0I've been using the > numeric_std library and eventually learned how to get around the > issues created by strong typing although it can be very arcane at > times. =A0I have read about a few suggestions people are making to help > with some aspects of the language, like a selection operator like > Verilog has. =A0But it just seems like I am always fighting some aspect > of the VHDL language. > > I guess part of my frustration is that I have yet to see where strong > typing has made a real difference in my work... at least an > improvement. =A0My customer uses Verilog and has mentioned several times > how he had tried using VHDL and found it too arcane to bother with. > He works on a much more practical level than I often do and it seems > to work well for him. > > One of my goals over the summer is to teach myself Verilog so that I > can use it as well as I currently use VHDL. =A0Then I can make a fully > informed decision about which I will continue to use. =A0I'd appreciate > pointers on good references, web or printed. > > Without starting a major argument, anyone care to share their feelings > on the differences in the two languages? > > Rick At the end of the day, it really comes down to how you can be more productive. If you tend to code with many levels of abstraction you may do better with VHDL. I find that I am more productive with Verilog, but it could be because I tend to look at hardware at a fairly detailed level, a bottom-up approach if you will. I inherited Verilog projects at my current place of employment and just stuck with the language as it grew on me. At one point I read Thomas & Moorby's green book from cover to cover. However it described Verilog 95, not the more commonly used Verilog 2001, and was not a particularly good reference book. I keep a copy of the Doulos Golden Reference handy for the bits I don't use every day. Good Luck, Gabor
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