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 Aug 10, 12:36=A0am, John Adair <g...@enterpoint.co.uk> wrote: > We have been looking at the FMC standard but it does have a pile of > problems for us and our potential customers. This specification was > written by a group of people all from companies, in the same market > sectors, and with a very limited vison as a result. Problems as I see > it: > > (1) The specification costs a lot to buy and will limit widespread > adoption and potential customer base. The VITA-57.1 specification cost is $75 and is only needed by a board designer. Having a uniform standard will allow for for wider collection of FMC modules that can be used on a wider set of boards for increase adoption. > (2) The format is very small even on the bigger version. The LPC (Low Pin Count) version has 68 IOs, 2 Clock Pairs, and 1 MGT TX/RX + REFCLK. The HPC (High Pin Count) version has 160 IOs, 4 Clock Pairs and 10 MGT TX/RX and 2 REFCLKs. Small is in the eye of the beholder. If you need more then you can move into a double wide configuration. > (3) A lot of on-module regulation will be needed further limiting what > else can be done on the module. I haven't put any voltage regulation on any of the FMC modules that we've designed so far, but I will on some that are coming up. The CC (Carrier Card) provides 12V, 3.3V and VADJ (0-3.3V) and the FMC can provide one voltage back to the CC (VIO_B). For most FMC this is enough, but if you need to a 5V rail then you will need to convert the 12V to 5V. Note: For Xilinx CC, we are fixing the VADJ supply to 2.5V to be compatible for both our Virtex-6 and Spartan-6 families IO standards. > (4) On small and medium size devices, e.g. most Spartans, it uses up > most I/O that we would normally use for our own headers and we can't > maintain our support for existing customers. There is no requirement that you must fill up all of the IOs on the LPC or HPC. The only requirement is that you start with the LA_00 to enable the highest degree of compatability. > (5) Connectors are very expensive and single source. I will say Samtec > is a very good supplier of connectors but even so if they go out of > business where are the connectors coming from. The connectors are no longer single sourced as Molex has an equivalent connector. http://www.molex.com/cmc_upload/0/000/-17/287/VITA-57CrossRef.pdf I think that the list price for the LPC is in the neighborhood of $7-8, does that really qualify as "very expensive". IMHO, Samtec going out of business is extremely low. > (6) The currently available FMC modules are many times the price of a > potential Spartan-6 board especially a starter kit Spartan-6. Modules will be priced at the level that the market will bear. The manufacturing cost between an FMC and a propiertary interface board will not be signficiantly different. If the non-FMC connector was a $0 cost, then the potential difference in cost is in the range of $7-8 as the PCB cost and component BOM would be the same. > (7) There may be IP or licensing issues as a result of the way the > spec is controlled and owned. It is an industry standard created under the auspices of VITA and approved by ANSI. Everyone involved in this were aware that they had to notify the commitee of any patent issues and were giving the proper time to make any disclosures as required by VITA and ANSI regulations. This is a very basic specification without a lot of overhead, most of it is all about the form factor and pin function locations to ensure compatability between cards. > That all said the attraction of common standard is a nice idea. I'm > just not sure of the practical and cost aspects of it as FMC currently > appears. There are so many connector standards that could have been > either reused or just used as is without a totally new standard. One > of my personal favorites is the PC104 connectors that we allready use > both in normal mode but also in custom fashions for some of our > products. We also do that just by FPGA configuration and that > selection doesn't affect the hardware aspects of our boards. > > I think we will adopt FMC on our high end Spartan-6 boards and maybe > have an adaptor available for our low end. We are looking at the > practicality of that. Our Virtex-6 boards may have this as standard > but we debating that. We will also > > John Adair > Enterpoint Ltd. > Ed McGettigan -- Xilinx Inc.Article: 142476
Frank Buss <fb@frank-buss.de> writes: > This would be a lifetime project for most students. I think starting with > low-level gates is a good idea. Keep in mind the original question - what should a Spartan-6 board be? I think most of the people getting such an eval board would want something that pushed the envelope, not something trivial. Besides, students can always add a low-level gate as a peripheral ;-)Article: 142477
Frank Buss <fb@frank-buss.de> wrote:
>DJ Delorie wrote:
>
>> Or better, have it ship pre-programmed to be a standalone web browser
>> - softcpu; drivers for vga, keyboard, mouse, ethernet; mini-OS,
>> browser. Plug everything in and go, then learn how to do it yourself.
>
>This would be a lifetime project for most students. I think starting with
>low-level gates is a good idea. First with real ones, like 7400 DIL. Then
>maybe with schematics editor and FPGAs, because it is much easier to build
>with the mouse than with wires, but the result, testing in real hardware,
>is the same. Finally some simple programs in VHDL. There are always some
>students who want to implement a web browser after this :-)
I think schematics entry is the worse thing to do when introducing
someone to an FPGA. Better to learn VHDL and look at the schematic
based on the synthesized result.
--
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
"If it doesn't fit, use a bigger hammer!"
--------------------------------------------------------------
Article: 142478Ed Even if the FMC connectors hit $7-8 that still a major hit when you sell modules in the area of $20-40 as many of our smaller modules are. As it happens we were formally quoted several times that number for the LPC FMC procluding anything other than mid to high range module products. If we get into partial I/O variants on this spec is that not going to defeat the purpose. I can just imagine the number of calls our support line will get if we have a partial I/O implementation on a board. Even if you have a FAQ saying so the number of people that will not see or understand the implications will be large. Out of interest do have some example pricing and types of module Xilinx will sell? John Adair Enterpoint Ltd. On 12 Aug, 16:50, Ed McGettigan <ed.mcgetti...@xilinx.com> wrote: > On Aug 10, 12:36=A0am, John Adair <g...@enterpoint.co.uk> wrote: > > > We have been looking at the FMC standard but it does have a pile of > > problems for us and our potential customers. This specification was > > written by a group of people all from companies, in the same market > > sectors, and with a very limited vison as a result. Problems as I see > > it: > > > (1) The specification costs a lot to buy and will limit widespread > > adoption and potential customer base. > > The VITA-57.1 specification cost is $75 and is only needed by a board > designer. Having a uniform standard will allow for for wider > collection of FMC modules that can be used on a wider set of boards > for increase adoption. > > > (2) The format is very small even on the bigger version. > > The LPC (Low Pin Count) version has 68 IOs, 2 Clock Pairs, and 1 MGT > TX/RX + REFCLK. =A0The HPC (High Pin Count) version has 160 IOs, 4 Clock > Pairs and 10 MGT TX/RX and 2 REFCLKs. =A0Small is in the eye of the > beholder. =A0If you need more then you can move into a double wide > configuration. > > > (3) A lot of on-module regulation will be needed further limiting what > > else can be done on the module. > > I haven't put any voltage regulation on any of the FMC modules that > we've designed so far, but I will on some that are coming up. The CC > (Carrier Card) provides 12V, 3.3V and VADJ (0-3.3V) and the FMC can > provide one voltage back to the CC (VIO_B). =A0For most FMC this is > enough, but if you need to a 5V rail then you will need to convert the > 12V to 5V. > > Note: For Xilinx CC, we are fixing the VADJ supply to 2.5V to be > compatible for both our Virtex-6 and Spartan-6 families IO standards. > > > (4) On small and medium size devices, e.g. most Spartans, it uses up > > most I/O that we would normally use for our own headers and we can't > > maintain our support for existing customers. > > There is no requirement that you must fill up all of the IOs on the > LPC or HPC. =A0The only requirement is that you start with the LA_00 to > enable the highest degree of compatability. > > > (5) Connectors are very expensive and single source. I will say Samtec > > is a very good supplier of connectors but even so if they go out of > > business where are the connectors coming from. > > The connectors are no longer single sourced as Molex has an equivalent > connector.http://www.molex.com/cmc_upload/0/000/-17/287/VITA-57CrossRef.p= df > I think that the list price for the LPC is in the neighborhood of > $7-8, does that really qualify as "very expensive". > > IMHO, Samtec going out of business is extremely low. > > > (6) The currently available FMC modules are many times the price of a > > potential Spartan-6 board especially a starter kit Spartan-6. > > Modules will be priced at the level that the market will bear. > > The manufacturing cost between an FMC and a propiertary interface > board will not be signficiantly different. If the non-FMC connector > was a $0 cost, then the potential difference in cost is in the range > of $7-8 as the PCB cost and component BOM would be the same. > > > (7) There may be IP or licensing issues as a result of the way the > > spec is controlled and owned. > > It is an industry standard created under the auspices of VITA and > approved by ANSI. =A0Everyone involved in this were aware that they had > to notify the commitee of any patent issues and were giving the proper > time to make any disclosures as required by VITA and ANSI > regulations. =A0This is a very basic specification without a lot of > overhead, most of it is all about the form factor and pin function > locations to ensure compatability between cards. > > > > > =A0That all said the attraction of common standard is a nice idea. I'm > > just not sure of the practical and cost aspects of it as FMC currently > > appears. There are so many connector standards that could have been > > either reused or just used as is without a totally new standard. One > > of my personal favorites is the PC104 connectors that we allready use > > both in normal mode but also in custom fashions for some of our > > products. We also do that just by FPGA configuration and that > > selection doesn't affect the hardware aspects of our boards. > > > I think we will adopt FMC on our high end Spartan-6 boards and maybe > > have an adaptor available for our low end. We are looking at the > > practicality of that. Our Virtex-6 boards may have this as standard > > but we debating that. We will also > > > John Adair > > Enterpoint Ltd. > > Ed McGettigan > -- > Xilinx Inc.Article: 142479
Rainer Buchty <buchty@atbode100.lrr.in.tum.de> wrote: < In article <1se3s9w5bxodj.1jbhy6iv9zya3$.dlg@40tude.net>, < Frank Buss <fb@frank-buss.de> writes: < |> This would be a lifetime project for most students. I think starting with < |> low-level gates is a good idea. First with real ones, like 7400 DIL. Then < |> maybe with schematics editor and FPGAs < I like to object here. < At our university we're teaching VHDL to undergrads and grads; the former < have no previous knowledge of hardware design. Therefore, they start with < simple tasks like blinkenlights and stuff, but then quickly move on to < design a VGA picture generator, and finally create their own pong clone, < altering the original gameplay by further ideas ranging from auto-player, < multi-ball, reverse-gravity etc. (A presentation of this course was recently < given at CDNlive2009 in Munich.) I thought the suggestion was for a frosh level introductory course. (Such as I previously, mentioned, a one term lecture course followed by a one term lab course.) I don't see anything wrong with VHDL for an upper level undergrad course, but for a first introduction to digital logic that seems hard to do. If someone has never thought about the ideas of digital logic, of wires connecting gates, starting directly in VHDL doesn't sound good to me. My understanding now is that some use simulation only for the introduction. That is, you have a graphical user interface where you move around virtual wires and virtual gates. You could even shape the gates into TTL chips and require the user to connect up Vcc and ground. Still, I think you miss something skipping at least one lab with a real TTL chip. I suppose I believe you could start an introduction to VHDL near the end of the lecture course, and if done carefully the later lab projects in the one term course could be done in VHDL. I definitely agree that upper level undergrad courses could be entirely in VHDL (which I prefer over schematic entry), but only if the students understand that the underlying technology is gates and wires. -- glenArticle: 142480
DJ Delorie <dj@delorie.com> wrote: < Frank Buss <fb@frank-buss.de> writes: <> This would be a lifetime project for most students. I think starting with <> low-level gates is a good idea. < Keep in mind the original question - what should a Spartan-6 board be? < I think most of the people getting such an eval board would want < something that pushed the envelope, not something trivial. I think that is my fault. There are plenty of boards around that can be used in upper level undergrad courses. I was trying to suggest something for introductory (frosh) and intermediate undergrad courses. I believe that part of the market is still underserved. I am not against more advanced boards, but it mgiht be time to also design a simpler board. < Besides, students can always add a low-level gate as a peripheral ;-) At FCCM95 I was part of a discussion on how to teach digital logic in the future. I was figuring that in not so many years TTL gates would be gone. It seems that they are still available for now, though. Much of the discussion was that FGPA companies should have free software that beginners could use. That problem seems to have been solved. -- glenArticle: 142481
Nagaraj escribió: > Dear all, > > I'm looking for the equivalent system gate figures (like in Actel > Igloo series) of Altera Cyclone II devices. Specifically, an > equivalent for the EP2C50 in the Igloo series. > > Any suggestion / link is highly appreciated. > > Nagaraj > In FPGA you must compare resources; never gates. So think about how many and which resources need to build your design. WalterArticle: 142482
Does anyone know if there are any reports or appnotes on the subject? I found a Xilinx report on GTP-MGT interoperability, but nothing on GTX-MGT. Thanks, /MikhailArticle: 142483
Nico Coesel wrote: > I think schematics entry is the worse thing to do when introducing > someone to an FPGA. Better to learn VHDL and look at the schematic > based on the synthesized result. That's worse, because understanding the produced schematics of non-trivial VHDL is really difficult, because it uses unusual gates, like lookup-elements and it is not layouted nicely like a human would do it. My suggestion was really for frosh level introductory course. For people who don't know the hot side of an iron. You should at least do one simple circuit with real TTL gates, maybe with some scope measuring, bad bouncing push buttons etc., to learn some of the basics from first hand. As John Adair wrote: It is difficult to understand the nasty side of the analog world, if you start with VHDL and something goes wrong. -- Frank Buss, fb@frank-buss.de http://www.frank-buss.de, http://www.it4-systems.deArticle: 142484
Rainer Buchty wrote: > Agreed, but probably not that low-level as Frank suggested, i.e. trying > to transform 74xx into VHDL models. Especially as the understanding > required for those kind of jobs definitely includes understanding of > the architecture and how things may be mapped onto it. You are right, maybe the schematics part on the FPGA could be skipped. But I think it is important to build some simple things with real TTL chips. After this you can continue with VHDL. > Regarding the mentioned undergrad course, one goal was getting an idea on > what it takes to create certain machine setups in hardware; in this very > case it was meant for preservation, i.e. designing full-system emulators > where the original software would still run on. The final lab project > therefore was about a compatible re-creation of an existing arcade machine > within an FPGA. Here, the focus was more put on understanding "alien" code, > extending it, and and making it work within an own design rather than > writing anything own stuff as required in the preceding tasks. > > If you're interested, the poster gives a quick overview: > http://itec.uka.de/~buchty/pub/2009-cdnlive-poster.pdf > > with the extended abstract being this: > http://itec.uka.de/~buchty/pub/2009-cdnlive.pdf This sounds like a good course. Learning all at once, implementing a CPU and coding the programs which runs on the CPU, would be more difficult. If you have already an architecture and some old assembler code, you can concentrate on designing a CPU for it. -- Frank Buss, fb@frank-buss.de http://www.frank-buss.de, http://www.it4-systems.deArticle: 142485
On Aug 12, 11:40=A0am, Test01 <cpan...@yahoo.com> wrote: > On Aug 12, 6:21=A0am, KJ <kkjenni...@sbcglobal.net> wrote: > > I am not trying to test the specifics of OSERDES and ISERDES in > design1. =A0Design1 contans a split transaction serial bus exerciser > that I need to use to test design2. =A0But design1 uses OSERDES and > ISERDES primitves to serilize the bit stream of the split transaction > bus as it was intended for normal I/O application. =A0Here I am trying > to figure out if I can use design1 as is to test design2. =A0It seems > that at minimum I need to replace the ISERDES and OSERDES with my own > serilizer and derserilizer verilog models to keep the low effort > level. I am trying to avoid designing design1 from scratch in order to You have three options, listed from worst to best (in my opinion) 1. Bring the design 1 SERDES outputs out to I/O pins and modify the board to connect these outputs to the inputs pins of design 2. 2. Re-read the second and third paragraph of my previous post and implement that instead. You do not need to write code for a serializer or a deserializer in order to implement the combined function of both. To do this you don't need to hack up design 1, you simply need to change the top level I/O of design 1 and design 2 to have a wider parallel interface and connect them together either with a bank of flops or a fifo as I suggested previously. Since this interface is all internal to the FPGA no I/O pin modifications to the board are required. 3. The best option is to simulate the system. Instantiate design 1 and design 2, connect the I/O appropriately, model other parts on the PCBA if necessary. Set up any other stimulus as required, run the simulation and verify that the design operates properly. This is the best and most accurate way of getting your design correct. Once skilled in this process it is far more productive than debug on hardware Kevin JenningsArticle: 142486
Dear all.
I wrote some HDL code for LUTs.
I tried both sequential and combinational way like
lutout <= 1 when sel = 0 else
78 when sel = 1 else
32 when sel = 2 else .......
and
case sel is
when 0 => lutout <= 1;
when 1 => lutout <= 78;
when 2 => lutout <= 32;
.......
In both cases, the synthesis tool (synplify, in my case) invoke Block
SelectRAMs for that LUTs.
synthesis:
@N: FX211 |Packed ROM u1701.lut012[30:23] (8 input, 8 output) to Block
SelectRAM
However, I want to keep them in gate logics since there are limited
numbers of memory blocks,
and I need to use them for other module.
The synthesis tool reports that the design used
>> 256x1 ROMs (ROM256X1): 1107, Block Rams : 288 of 288 (100%)
as a result, the mapping tool reports overmapping error
>> Number of BlockRAM/FIFO: 369 out of 288 128% (OVERMAPPED)
Since the logic utilization is still around 40%, I think I can use
slices for that LUTs.
Can I force the synthesis tool to do not use Block Rams for that LUTs?
Thanks for reading.
S. Jin
Article: 142487Thanks, Kolja On Aug 11, 9:24=A0pm, Kolja <ksuli...@googlemail.com> wrote: > On 11 Aug., 11:01, jogging <joggings...@gmail.com> wrote:> =A0In IC desgi= n, the first step is algorithm > > design and C model implementation. > > I always wondered why anyone would want to model the algorithms in > C nowadays. There are so many nice modern languages around with > object orientation, etc. > Prototyping should be much quicker and less error prone with any of > these > compared to C. I am not a IC design engineer, so not familiar with practice in IC industry. I'm only curious the way how the gap between algorithm design and FPGA implementation is solved. From wikipedia, it says ESL design: This step creates the user functional specification. The user may use a variety of languages and tools to create this description. Examples include a C/C++ model, SystemC, SystemVerilog Transaction Level Models, Simulink and MATLAB. Do you mean MATLAB is used to develop prototype? What are the most popular languages to develop prototype? > > > Do algorithm > > engineers need to know FPGA implementation details > > In this step? > > I think it is sufficient to have some information on the cost of > various > operations, like the number and size of RAMs, Multipliers, FIFOs etc. > And some informations on the relativ speed of these operations. > > Kolja Sulimma Best Regards JoggingArticle: 142488
Just saw this threat ... Peter, all the best wishes, I hope we will keep seeing you around and can continue to count on your feedback where it matters. Good Luck, rudiArticle: 142489
On Aug 13, 4:59=A0am, coredev <core...@gmail.com> wrote: > Dear all. > > I wrote some HDL code for LUTs. > I tried both sequential and combinational way like > > lutout <=3D 1 when sel =3D 0 else > =A0 =A0 =A0 =A0 =A0 =A0 =A078 when sel =3D 1 else > =A0 =A0 =A0 =A0 =A0 =A0 =A032 when sel =3D 2 else ....... > > and > > case sel is > when 0 =3D> lutout <=3D 1; > when 1 =3D> lutout <=3D 78; > when 2 =3D> lutout <=3D 32; > ....... > > In both cases, the synthesis tool (synplify, in my case) invoke Block > SelectRAMs for that LUTs. > > synthesis: > @N: FX211 |Packed ROM u1701.lut012[30:23] (8 input, 8 output) to Block > SelectRAM > > However, I want to keep them in gate logics since there are limited > numbers of memory blocks, > and I need to use them for other module. > > The synthesis tool reports that the design used>> 256x1 ROMs (ROM256X1): = 1107, Block Rams : 288 of 288 (100%) > > as a result, the mapping tool reports overmapping error > > >> =A0 Number of BlockRAM/FIFO: 369 out of =A0 =A0 288 =A0128% (OVERMAPPE= D) > > Since the logic utilization is still around 40%, I think I can use > slices for that LUTs. > Can I force the synthesis tool to do not use Block Rams for that LUTs? > > Thanks for reading. > > S. Jin look synthesis attributes, you can disable the block ram from some block/signal entity our client just had similar problem where they needed small ROM to be implemented in non block RAM they had initially small problem, they prohibited block RAM, but not block ROM, but after changing constraint to not use block rom it worked well AnttiArticle: 142490
"jogging" <joggingsong@gmail.com> wrote in message news:b67735ce-69c4-4e5a-81d0-9afaa25f54e7@v20g2000yqm.googlegroups.com... Thanks, Kolja On Aug 11, 9:24 pm, Kolja <ksuli...@googlemail.com> wrote: > On 11 Aug., 11:01, jogging <joggings...@gmail.com> wrote:> In IC desgin, the > first step is algorithm > > design and C model implementation. > > I always wondered why anyone would want to model the algorithms in > C nowadays. There are so many nice modern languages around with > object orientation, etc. > Prototyping should be much quicker and less error prone with any of > these > compared to C. >I am not a IC design engineer, so not familiar with practice in IC >industry. >I'm only curious the way how the gap between algorithm design and >FPGA implementation is solved. >From wikipedia, it says >ESL design: This step creates the user functional specification. The >user may use a variety of languages and tools to create this >description. Examples include a C/C++ model, SystemC, SystemVerilog >Transaction Level Models, Simulink and MATLAB. >Do you mean MATLAB is used to develop prototype? yes, Matlab is quite popular for algorithmic model development. You can then translate your m-code to C and use it in your virtual system and/or put a SystemC wrapper around it and use it in your RTL simulation. >What are the most popular languages to develop prototype? I believe C/C++ are still the most widely used prototype languages followed by SystemVerilog/SystemC Hans www.ht-lab.com > > > Do algorithm > > engineers need to know FPGA implementation details > > In this step? > > I think it is sufficient to have some information on the cost of > various > operations, like the number and size of RAMs, Multipliers, FIFOs etc. > And some informations on the relativ speed of these operations. > > Kolja Sulimma Best Regards JoggingArticle: 142491
Fabian Schuh schrieb: > Hello group, > > I am trying to acces some IOB from within a partial reconfigurable > module (prm). > > The arch would look like this: > > /- IOB > | > |---------------------|----| > ||--------------| |---|---|| > || | | || > || static part | | PRM || > || |-| || > || |-| || > || |-| || > || |-| || > || | | || > || | | || > || | | || > ||--------------| |-------|| > |--------------------------| > > Between both modules, there are the busmacros. > Those are working great. Anyway, the IOB located above the prm must be > connected to the prm. No busmacros. I tried so by connecting the IOB > (named debug_io(21)) within the toplevel design. > ++++++++++++++++++++++++ > mod_can_wrapper: mod_can > port map ( > ... > id => debug_io(21), > ... > ); > ++++++++++++++++++++++++ > > The problem appears while running 'par': > ++++++++++++++++++++++++ > ERROR: Net debug_io_21_IBUF crosses a region boundary and is not part of > a slice macro. > Nets crossing region boundaries must be part of a slice macro > ++++++++++++++++++++++++ > I remeber setting the -iobuf option of 'xst' to no, so the module itself > does not add ibufs to the interface signals. > > > My question is: How can I access IOBs from within the module? > > Thanks for your help > > Sincerely > -- Fabian Schuh Hi there, found the relevant part in "Xilinx Development System Reference Guide" <www.xilinx.com/itp/xilinx8/books/docs/dev/dev.pdf> It says on page 110: +++++++++++++++++++++++++++++ External I/Os in a Module It is recommended that you declare external I/Os in the top-level design. However, you can include external I/Os in a module without modifying the top-level code. This may be useful if you want to add a temporary external I/O in the module for simulation. To do this, explicitly instantiate IBUF/IBUFG/BUFGP and OBUF connections. Following are examples of code. Note: Do not directly connect these I/Os to module ports. +++++++++++++++++++++++++++++ Greetz -- FabianArticle: 142492
Fabian Schuh schrieb: > Fabian Schuh schrieb: >> Hello group, >> >> I am trying to acces some IOB from within a partial reconfigurable >> module (prm). >> >> The arch would look like this: >> >> /- IOB >> | >> |---------------------|----| >> ||--------------| |---|---|| >> || | | || >> || static part | | PRM || >> || |-| || >> || |-| || >> || |-| || >> || |-| || >> || | | || >> || | | || >> || | | || >> ||--------------| |-------|| >> |--------------------------| >> >> Between both modules, there are the busmacros. >> Those are working great. Anyway, the IOB located above the prm must be >> connected to the prm. No busmacros. I tried so by connecting the IOB >> (named debug_io(21)) within the toplevel design. >> ++++++++++++++++++++++++ >> mod_can_wrapper: mod_can >> port map ( >> ... >> id => debug_io(21), >> ... >> ); >> ++++++++++++++++++++++++ >> >> The problem appears while running 'par': >> ++++++++++++++++++++++++ >> ERROR: Net debug_io_21_IBUF crosses a region boundary and is not part >> of a slice macro. >> Nets crossing region boundaries must be part of a slice macro >> ++++++++++++++++++++++++ >> I remeber setting the -iobuf option of 'xst' to no, so the module >> itself does not add ibufs to the interface signals. >> >> >> My question is: How can I access IOBs from within the module? >> >> Thanks for your help >> >> Sincerely >> -- Fabian Schuh > > Hi there, > > found the relevant part in "Xilinx Development System Reference Guide" > <www.xilinx.com/itp/xilinx8/books/docs/dev/dev.pdf> > > It says on page 110: > +++++++++++++++++++++++++++++ > External I/Os in a Module > It is recommended that you declare external I/Os in the top-level > design. However, you > can include external I/Os in a module without modifying the top-level > code. This may be > useful if you want to add a temporary external I/O in the module for > simulation. To do > this, explicitly instantiate IBUF/IBUFG/BUFGP and OBUF connections. > Following are > examples of code. > Note: Do not directly connect these I/Os to module ports. > +++++++++++++++++++++++++++++ > > Greetz > -- Fabian Hi again, The verilog example description is more precise: ++++++++++++++++++++ In the following example, the module has two external inputs (IPAD_MODA_CLK and IPAD_MODA_DATA) and one external output (OPAD_MODA_OUT). These external I/Os, IBUF, OBUF, and BUFGP are instantiated. The lower-level port declaration is different from the top-level declaration of module_a. Lower-level module_a has three additional ports. With Modular Design, NGDBuild ignores this port mismatch and uses module_a.edf to describe module_a. These I/Os will be present in the design and available for simulation. ++++++++++++++++++++ Greetz -- FabianArticle: 142493
I create a embed processor under ISE top module . After I instantiate it , I can 't synthesize it . In fact , synthesizer don't run and don't give any error report. I use XST synthesizer. I suspect I make some mistake in my program. So I output/input all port of this processor to external pin. Now synthesizer work. But even I don't instantiate one output port of this processor. The synthesizer don't work. In the past , I can leave the ouput port of sub module as blank , and no problem happen . Can some one give me some advice.Article: 142494
Hi all, I just recently tried out the nice Xilinx EDK, mainly because of the MicroBlaze processor. With the tools provided from Xilinx, it seems that the only way to simulate a system containing peripherals, processors, FSLs etc is to use HDL simulation. Unfortuntaly, HDL simulation is slow. I would rather like to have a software simulation for EDK systems. I understand that the deprecated Virtual Platform offered such a thing. Benefits of a software simulation I would expect are faster prototyping (evaluating different systems fast), and easier testing of software applications for such systems (in case no FPGA is available just right now, or to benchmark those systems better). An ideal system would be cycle-accurate, and good system would be timing-approximate, a still usable system would just provide correct results from the tested software. One option I saw was to model all the used EDK components and proprietary IP with e.g. SystemC, similar to SoCLib (https:// www.soclib.fr/trac/dev/wiki). Another option I just found is similar to the one described in the paper "A Multi-MicroBlaze Based SOC System: From SystemC Modeling to FPGA Prototyping" by S. Xu and H. Pollitt-Smith. They developed models for BRAM, OBP, etc and used a wrapper around the MicroBlaze ISS that communicates with their SystemC model. Does anybody of you have good ideas how such a system could be realized, or is aware of any tools (even commercial) that I have not found yet? Thank you a lot in advance! I would like to evaluate different systems fast, and to test software applications for such a system in a software simulation. In the best case, the system would To evaluate systems and to provide a tool to test applications for such a system I would likeArticle: 142495
Hi, I am looking into starting with FPGA's, and as I am looking for the cheapest solution to start programming, I'm thinking of getting the JTAGkey-Tiny: http://www.amontec.com/jtagkey-tiny.shtml My question is, if it is possible to use it in the similar sense that the big JTAGkey is advertised: "upload Altera, Atmel, Cypress, Lattice, Xilinx FPGA / CPLD with your SVF files." (http://www.amontec.com/jtagkey.shtml). I am aware that most likely not all chips will be supported, and having to make own connections and a host of other factors will increase the probability of errors - but if it is in principle possible, I'd be willing to try it. If it is possible to program (some of) these chips with JTAGkey-Tiny, I see that the JTAGkey-Tiny has a 20 pin header, whereas: "Xilinx and Altera FPGAs use six and 10 pins respectively for their JTAG interfaces. The Xilinx one just uses Vcc, Gnd, TCK, TDO, TDI and TMS." (http://www.xlinkers.org/forum/viewtopic.php?f=7&t=104) Is there information available on how to pull these 6(10) wire interface from the 20 pin header? If anyone has had experience with this, it would be great to see some comments ! :) Cheers !Article: 142496
Have a look here: http://www.digilentinc.com/Products/Catalog.cfm?NavPath=2,395&Cat=5&gclid=CNOuiNHPoJwCFdYB4wodumJvew for some cheap JTAG cables that might already have the correct connector for the board you want to use. JonArticle: 142497
On Aug 13, 3:03=A0pm, "sdaau" <s...@imi.aau.dk> wrote: > Hi, > > I am looking into starting with FPGA's, and as I am looking for the > cheapest solution to start programming, I'm thinking of getting the > JTAGkey-Tiny: > > http://www.amontec.com/jtagkey-tiny.shtml > > My question is, if it is possible to use it in the similar sense that the > big JTAGkey is advertised: "upload Altera, Atmel, Cypress, Lattice, Xilin= x > FPGA / CPLD with your SVF files." (http://www.amontec.com/jtagkey.shtml).= I > am aware that most likely not all chips will be supported, and having to > make own connections and a host of other factors will increase the > probability of errors - but if it is in principle possible, I'd be willin= g > to try it. > > If it is possible to program (some of) these chips with JTAGkey-Tiny, I > see that the JTAGkey-Tiny has a 20 pin header, whereas: > > "Xilinx and Altera FPGAs use six and 10 pins respectively for their JTAG > interfaces. The Xilinx one just uses Vcc, Gnd, TCK, TDO, TDI and TMS." > (http://www.xlinkers.org/forum/viewtopic.php?f=3D7&t=3D104) > > Is there information available on how to pull these 6(10) wire interface > from the 20 pin header? If anyone has had experience with this, it would = be > great to see some comments ! :) > > Cheers ! sure its possible, just the connector is ARM standard 20 pin so you need to remap the jtag lines. but it works very nicely, you can program pretty much any JTAG devices (FPGA's..too!) AnttiArticle: 142498
Mikhail, They are both designed to standards, so they are compatible if each is using the same standard (same rate, and data format). Of one note, check the common mode voltages for the standard: in some cases AC coupling is required, (although I think this is only true for the lower voltage GTX to higher supply voltage GTP).Article: 142499
braver wrote:
> In the past , I can leave the ouput port of sub module as blank , and
> no problem happen .
> Can some one give me some advice.
Synthesis works from port to port on the top module/entity.
No ports, no gates.
-- Mike Treseler
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