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
rickman wrote: > > Russell wrote: > > > > I think the fpga world would benefit greatly if the fpga vendors > > would just write an api library for each device to control all > > the low level logic primitives, and let open-source on linux > > take care of building state of the art routing and layout tools > > and decent hdl languages and compilers. It would improve the > > industry no end. How excellent would it be to be able to locate > > and fix a router bug your self, or get it fixed in less than > > a week? > > That may sound great in theory, but the software is vitally important to > an FPGA vendor. An FPGA vendor can't depend on outside factors to > control their destiny. An FPGA company can literally be made or broken > on the tools. So you will never see them abandon their in house tools > for open source tools. In fact, because the user community is so small, > they can't afford to develop the tools without the finance support of > the user base. If even just 50% of them go to open source tools the > FPGA vendor will lose tons of money. They can't raise the price of the > silcon to make up for it since the price of silicon is set by > competitive pressures. It would be a very tough sell to show that it > would provide a superior market position to have open source tools. > > Of course when I say they "can't afford" to self fund the tools, that is > a relative term. The point is that the tools cost a lot of money to > maintain and update. The economics are not there to allow open source > tools to compete. All the fpga vendors need to do is make a publicly available API for the devices, and keep doing whatever tools they have now. Private and public projects will start up for various reasons such as profit, academic purposes, or just to improve on what's available. Eventually the GPL tools will be better than those done by nine-to-fivers that couldn't give a stuff about fixing bugs. The fpga vendors can then either support the GPL tools and keep frozen releases for safety, or just keep doing their own tools but get useful ideas from the GPL tools. There'd be less problems for everyone if there was a choice of tools, and savings for the fpga vendors.Article: 48051
Petter Gustad <newsmailcomp3@gustad.com> writes: > I know how to set X11 resources using xrdb. The problem is to know > which resources are read by Quartus (if any). I don't think it's a > problem with settings in fvwm2 since no application behaves this way > other than Quartus (unless there is an option used by Quartus only). You could try 'editres', but I doubt Quartus will respond with useful info. Another way might be to trace system calls with 'strace'. My guess is that it sets an X property like "override redirect" on the main window which would make it stay on top like you describe (but "override redirect" would also bring it out of reach of the window manager AIUI). If you don't get an answer form Altera, I'd try asking on comp.windows.x. HTH, ColinArticle: 48053
I try to avoid doing hard macros, rather I stick to RPMs because they work better with the
conventional tool flow. In the past, the router has done a pretty good job in most cases if
the placement was good, so I rarely found the need to do hard macros other than as a
work-around. 4.2i does not do as good a job of finding a good routing solution given a good
placement, which means that there is more to gain from doing hard macros. I haven't had a
chance to evaluate 5.1's routing yet, but I suspect the finish sooner mentality has only
made the routing less optimal.
Russell wrote:
> My designs just use cascades of fairly repetitive filter and delay blocks
> which is well suited to macro methods, and they're controlled with some
> state-machine random logic. It should fit in the larger spartan devices.
>
> I heard that 4.2i fpga editor had bugs where vcc-gnd shorts happened.
> Is the 5.1i fpga editor much better? Are hard macros relatively bug-free
> to generate and use in 5.1i?
>
> Ray Andraka wrote:
> >
> > Bad news on 5.1. RPMs slow the mapping waaay down, at least big RPMs do. See my
> > previous post. I haven't tried the floorplanner in 5.1 yet.
> >
> > 4.2i's floorplanner has a workaround if your design will go through PAR without a
> > floorplan, you can then go into the floorplanner do a constrain from placement on your
> > RPMs, then unbind, then rebind each RPM, then you can move them around. Of course, it
> > does no good if your design won't make it through PAR without a floorplan, and it
> > doesn't leave much room to move things around if youve got a dense device.
> >
> > I've more or less had to use RLOC_ORIGIN constraints in the UCF to take care of
> > floorplanning RPMs under 4.2. I don't like it, but at least it is possible (reminds
> > me too much of the days before the introduction of the floorplanner in XACT.
> >
> > Russell wrote:
> >
> > > I gave up on doing any fpga design after wasting weeks on discovering
> > > how broken floor planning with RPMs in 4.2i was, and there's no way i
> > > can do without manual floorplanning. Altera had even less options and
> > > the devices had no SRL16 equivalent. If 5.1i is no good, i'll start
> > > investigating the cyclone devices. It would be good having a tool
> > > that runs on linux too (wonder if i still need that leonardo with
> > > the crappy gui bugs?). I was hoping 5.1i would fix everything, but
> > > i haven't tried it yet.
> > >
> > > Ray Andraka wrote:
> > > >
> > > > Same way we did before there was a floorplanner GUI: RLOCs and graph paper. How
> > > > do you floorplan with the broken floorplanner GUI in 4.2i?
> > > >
> > > > Russell wrote:
> > > >
> > > > >
> > > > > How do you floor-plan without a gui?
--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com
"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
Article: 48054Colin Marquardt <c.marquardt@alcatel.de> writes: > Petter Gustad <newsmailcomp3@gustad.com> writes: > > > I know how to set X11 resources using xrdb. The problem is to know > > which resources are read by Quartus (if any). I don't think it's a > > problem with settings in fvwm2 since no application behaves this way > > other than Quartus (unless there is an option used by Quartus only). > > You could try 'editres', but I doubt Quartus will respond with useful > info. Another way might be to trace system calls with 'strace'. No, editres respond with: It appears that the client does not understand the editres protocol. strace is a little difficult since Quartus is forking out several processes (typically 17 of them). Of course I could attach each of them to strace with the -p option, but it's a lot of work... > My guess is that it sets an X property like "override redirect" on > the main window which would make it stay on top like you describe > (but "override redirect" would also bring it out of reach of the > window manager AIUI). If you don't get an answer form Altera, I'd > try asking on comp.windows.x. Good suggestion. I'll try some other window manager first to see if I can get any clues from that first. Petter -- ________________________________________________________________________ Petter Gustad 8'h2B | ~8'h2B http://www.gustad.com/petterArticle: 48055
some clarification:
The hard macros don't exactly guarantee much more than an RPM does, as they also do not lock
down the routing. What it does do is lock down the pins of the LUTs, which will serve to bias
the router to use similar routing. However, if you have additional routes through the area, it
can make routing harder and can actually degrade the timing when compared to a regular RPM. We
used to be able to assign the pins to the lut back in the XACT days, but that capability
dissappeared with the M.1 tools. You can still trick it into using specific pins with some
limitations by replacing the LUTs with SRL16's and holding the WE input inactive for those cases
where you want to lock down LUT pins. Again, I try to avoid this low level, especially since it
obfuscates the code and can hamstring the router.
Ray Andraka wrote:
> I try to avoid doing hard macros, rather I stick to RPMs because they work better with the
> conventional tool flow. In the past, the router has done a pretty good job in most cases if
> the placement was good, so I rarely found the need to do hard macros other than as a
> work-around. 4.2i does not do as good a job of finding a good routing solution given a good
> placement, which means that there is more to gain from doing hard macros. I haven't had a
> chance to evaluate 5.1's routing yet, but I suspect the finish sooner mentality has only
> made the routing less optimal.
>
> Russell wrote:
>
> > My designs just use cascades of fairly repetitive filter and delay blocks
> > which is well suited to macro methods, and they're controlled with some
> > state-machine random logic. It should fit in the larger spartan devices.
> >
> > I heard that 4.2i fpga editor had bugs where vcc-gnd shorts happened.
> > Is the 5.1i fpga editor much better? Are hard macros relatively bug-free
> > to generate and use in 5.1i?
> >
> > Ray Andraka wrote:
> > >
> > > Bad news on 5.1. RPMs slow the mapping waaay down, at least big RPMs do. See my
> > > previous post. I haven't tried the floorplanner in 5.1 yet.
> > >
> > > 4.2i's floorplanner has a workaround if your design will go through PAR without a
> > > floorplan, you can then go into the floorplanner do a constrain from placement on your
> > > RPMs, then unbind, then rebind each RPM, then you can move them around. Of course, it
> > > does no good if your design won't make it through PAR without a floorplan, and it
> > > doesn't leave much room to move things around if youve got a dense device.
> > >
> > > I've more or less had to use RLOC_ORIGIN constraints in the UCF to take care of
> > > floorplanning RPMs under 4.2. I don't like it, but at least it is possible (reminds
> > > me too much of the days before the introduction of the floorplanner in XACT.
> > >
> > > Russell wrote:
> > >
> > > > I gave up on doing any fpga design after wasting weeks on discovering
> > > > how broken floor planning with RPMs in 4.2i was, and there's no way i
> > > > can do without manual floorplanning. Altera had even less options and
> > > > the devices had no SRL16 equivalent. If 5.1i is no good, i'll start
> > > > investigating the cyclone devices. It would be good having a tool
> > > > that runs on linux too (wonder if i still need that leonardo with
> > > > the crappy gui bugs?). I was hoping 5.1i would fix everything, but
> > > > i haven't tried it yet.
> > > >
> > > > Ray Andraka wrote:
> > > > >
> > > > > Same way we did before there was a floorplanner GUI: RLOCs and graph paper. How
> > > > > do you floorplan with the broken floorplanner GUI in 4.2i?
> > > > >
> > > > > Russell wrote:
> > > > >
> > > > > >
> > > > > > How do you floor-plan without a gui?
>
> --
> --Ray Andraka, P.E.
> President, the Andraka Consulting Group, Inc.
> 401/884-7930 Fax 401/884-7950
> email ray@andraka.com
> http://www.andraka.com
>
> "They that give up essential liberty to obtain a little
> temporary safety deserve neither liberty nor safety."
> -Benjamin Franklin, 1759
--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com
"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
Article: 48056Hello, Hopefully an easy question: If I have a single bit signal that is initialised to either 0 or 1 such as: signal INIT : std_logic := '1'; how exactly is this initialised into a slice? I assume it ends up as the output of one of the flip-flops but is it set directly into the RAM cell of the flip-flop by the bitstream or does it go into the LUT and is then clocked into the flip-flop - or is it set by some other means? I had a look on google groups and found some posts but they don't seem to describe how the value is actually set from the bitstream. Thanks for your time. KenArticle: 48057
Jens, In my previous posting I said that I used the BIT file. Looking at the project I can see that I used the HEX file output,and I had the "swap bits" option checked when I created it. The only problems we had were at the end of the programming process. There is a delay between writing the last data bit and the Spartan asserting the DONE line. We ended up putting in a 5 second timeout loop that polls the DONE bit. After the DONE bit is asserted, the Spartan needs three extra CCLK cycles to put it into operate mode. This wasn't explained well in the documentation. Regards, Chris Jens Niemann wrote: >Hello, >is there somewhere a reference design or some information about booting a >SRAM-based FPGA via a USB interface? >I am thinking to use one of Cypress's USB interfaces to programm a Spartan >2 via JTAG. This would be a very convenient solution for further programm >updates. >Any suggestions ? > >Regards, >Jens Niemann > > > >Article: 48058
Hi Ken, The initialisation value assigned to a signal when it is defined (signal global_rst: std_logic;) is ignored during synthesis. It's valid for simulation only and most of today's synthesis tools will flag that as a WARNING and just ignore it. Regards -- Ulises Hernandez Design Engineer ECS Technology Limited ulisesh@ecs-tech.com "Ken Mac" <aeu96186@yahoo.co.uk> wrote in message news:ao3uc8$gb1$1@dennis.cc.strath.ac.uk... > > Hello, > > Hopefully an easy question: > > If I have a single bit signal that is initialised to either 0 or 1 such as: > > signal INIT : std_logic := '1'; > > how exactly is this initialised into a slice? > > I assume it ends up as the output of one of the flip-flops but is it set > directly into the RAM cell of the flip-flop by the bitstream or does it go > into the LUT and is then clocked into the flip-flop - or is it set by some > other means? > > I had a look on google groups and found some posts but they don't seem to > describe how the value is actually set from the bitstream. > > Thanks for your time. > > Ken > >Article: 48059
Hi Ken, what Ulises said is correct, if you only put a init-value onto a signal then it will be ignored. However as you know the flipflops do not start up in a random state but on a defined value. The default-value would be '0' but you can set a differnt value via the UCF-file or via an attribute in your VHDL. That's what you do in the tools. In hardware the init-values are part of the bit-stream and are loaded during configuration. When you download the bit-stream the flipflops (and BTW all the other bits and pieces of the device) get the information what they have to do when the device is configured. Means all the bits of the bitstream are written into the appropriate locations and when your DONE-pin goes high and GSR (global set reset) is de-asserted you have an FPGA with the configuration you described in your VHDL/etc. So you don't have to clock e.g. bits from LUTs into FFs or something like that. Hope that helps, Martin Ken Mac wrote: > Hello, > > Hopefully an easy question: > > If I have a single bit signal that is initialised to either 0 or 1 such as: > > signal INIT : std_logic := '1'; > > how exactly is this initialised into a slice? > > I assume it ends up as the output of one of the flip-flops but is it set > directly into the RAM cell of the flip-flop by the bitstream or does it go > into the LUT and is then clocked into the flip-flop - or is it set by some > other means? > > I had a look on google groups and found some posts but they don't seem to > describe how the value is actually set from the bitstream. > > Thanks for your time. > > Ken > > >Article: 48060
Ok - I'd better do a bit of a rethink and use a RESET signal in that case! Thanks for the info. Ken > The initialisation value assigned to a signal when it is defined (signal > global_rst: std_logic;) is ignored during synthesis. > It's valid for simulation only and most of today's synthesis tools will flag > that as a WARNING and just ignore it.Article: 48061
Yes. It has been done. Several times. On Thu, 10 Oct 2002 09:33:40 +0530, "geeko" <jibin@ushustech.com> wrote: > > In this age of multigigabit networks TCP/IP processing with >software will cause perfomance degradation .What are the possiblities of an >TCP/IP hardware which will do all the TCP/IP processing and store the >packets in a buffer so that the application can use it.Is any similar system >is available >Article: 48062
Bob W <fa@_NO_SPAM_AskTheOracle.com> wrote in message news:<ac37qu81b5ctfse55tdbdp1jt1cges506i@4ax.com>... > On Wed, 9 Oct 2002 00:55:03 +0100, "Tim" > <tim@rockylogic.com.nooospam.com> wrote: > > be up the industry standard :-) > > > >My biggest Xilinx gripe is that lots of their error messages are > >plainly generated by 'assert' failures, and nobody has taken > >the trouble to scan the source for the asserts and document > >them. Then tech support treat you as a nutcase when you report > >the error... > > > > I was at a design seminar for the Xilinx MicroBlaze embedded > processor. Some asked what all of those warning messages are that are > scrolling through the screen. The instructor says, "Oh those are the > normal Xilinx warnings. Just ignore them". How come it generates so > many warnings even when its working? I asked the same thing of our FAE. He said that some of the warnings are things that Xilinx may eventually turn into error messages - especially case sensitivity disagreements between the ucf and edf. It's really too bad they don't provide you a way to enable/disable the minor warnings... that would actually make it usable. As it is right now, all warnings get ignored. As for Xilinx vs. Altera SW, the Xilinx software appears to be slightly more powerful (in terms of most features), but Altera's is much nicer to use. But as nice as Altera's software is, and as affordable as the 20KE parts are, it doesn't seem to be able to handle (successfully map and meet timing) one of our XC2V3000 designs, so we have no choice but to stick with Xilinx. MarcArticle: 48063
Hello Ray, Hard macros (.nmc) can indeed contain routing information, but this is functionality is not often used. Here's a brief description of hard macro use cases: 1. Unplaced and unrouted hard macros - The macro is used to define only the component configuration and PAR is free to place and route as needed. 2. Placed and unrouted hard macros - The macro defines the component configuration and relative placement of the components. The router is free to route the macro as needed. 3. Placed and routed hard macros - The macro defines the component configuration, relative placement and routing of the macro. The problem with hard macros is that they exist only as a black box in the logical design so they complicate timing analysis and simulation. A combination of RPMs with Directed Routing contains the same functionality without this limitation. For that reason, hard macros tend to be used only as work arounds to force implementations that map/par can't handle. Regards, Bret Ray Andraka wrote: > some clarification: > > The hard macros don't exactly guarantee much more than an RPM does, as they also do not lock > down the routing. What it does do is lock down the pins of the LUTs, which will serve to bias > the router to use similar routing. However, if you have additional routes through the area, it > can make routing harder and can actually degrade the timing when compared to a regular RPM. We > used to be able to assign the pins to the lut back in the XACT days, but that capability > dissappeared with the M.1 tools. You can still trick it into using specific pins with some > limitations by replacing the LUTs with SRL16's and holding the WE input inactive for those cases > where you want to lock down LUT pins. Again, I try to avoid this low level, especially since it > obfuscates the code and can hamstring the router. > > Ray Andraka wrote: > > > I try to avoid doing hard macros, rather I stick to RPMs because they work better with the > > conventional tool flow. In the past, the router has done a pretty good job in most cases if > > the placement was good, so I rarely found the need to do hard macros other than as a > > work-around. 4.2i does not do as good a job of finding a good routing solution given a good > > placement, which means that there is more to gain from doing hard macros. I haven't had a > > chance to evaluate 5.1's routing yet, but I suspect the finish sooner mentality has only > > made the routing less optimal. > > > > Russell wrote: > > > > > My designs just use cascades of fairly repetitive filter and delay blocks > > > which is well suited to macro methods, and they're controlled with some > > > state-machine random logic. It should fit in the larger spartan devices. > > > > > > I heard that 4.2i fpga editor had bugs where vcc-gnd shorts happened. > > > Is the 5.1i fpga editor much better? Are hard macros relatively bug-free > > > to generate and use in 5.1i? > > > > > > Ray Andraka wrote: > > > > > > > > Bad news on 5.1. RPMs slow the mapping waaay down, at least big RPMs do. See my > > > > previous post. I haven't tried the floorplanner in 5.1 yet. > > > > > > > > 4.2i's floorplanner has a workaround if your design will go through PAR without a > > > > floorplan, you can then go into the floorplanner do a constrain from placement on your > > > > RPMs, then unbind, then rebind each RPM, then you can move them around. Of course, it > > > > does no good if your design won't make it through PAR without a floorplan, and it > > > > doesn't leave much room to move things around if youve got a dense device. > > > > > > > > I've more or less had to use RLOC_ORIGIN constraints in the UCF to take care of > > > > floorplanning RPMs under 4.2. I don't like it, but at least it is possible (reminds > > > > me too much of the days before the introduction of the floorplanner in XACT. > > > > > > > > Russell wrote: > > > > > > > > > I gave up on doing any fpga design after wasting weeks on discovering > > > > > how broken floor planning with RPMs in 4.2i was, and there's no way i > > > > > can do without manual floorplanning. Altera had even less options and > > > > > the devices had no SRL16 equivalent. If 5.1i is no good, i'll start > > > > > investigating the cyclone devices. It would be good having a tool > > > > > that runs on linux too (wonder if i still need that leonardo with > > > > > the crappy gui bugs?). I was hoping 5.1i would fix everything, but > > > > > i haven't tried it yet. > > > > > > > > > > Ray Andraka wrote: > > > > > > > > > > > > Same way we did before there was a floorplanner GUI: RLOCs and graph paper. How > > > > > > do you floorplan with the broken floorplanner GUI in 4.2i? > > > > > > > > > > > > Russell wrote: > > > > > > > > > > > > > > > > > > > > How do you floor-plan without a gui? > > > > -- > > --Ray Andraka, P.E. > > President, the Andraka Consulting Group, Inc. > > 401/884-7930 Fax 401/884-7950 > > email ray@andraka.com > > http://www.andraka.com > > > > "They that give up essential liberty to obtain a little > > temporary safety deserve neither liberty nor safety." > > -Benjamin Franklin, 1759 > > -- > --Ray Andraka, P.E. > President, the Andraka Consulting Group, Inc. > 401/884-7930 Fax 401/884-7950 > email ray@andraka.com > http://www.andraka.com > > "They that give up essential liberty to obtain a little > temporary safety deserve neither liberty nor safety." > -Benjamin Franklin, 1759Article: 48064
"MikeJ" <pacman@fpgaarcade.com> schrieb im Newsbeitrag news:1034208063.92802.0@dyke.uk.clara.net... > Xilinx tools are not interesting, they don't need to be. Many designers > never even run up the gui. The simulator is where the action is. From which planet are you from? Ahhh, you one of this REAL men, that work hard to the basics (command line) and shunn all this GUI sissys. Njoy. -- MfG FalkArticle: 48065
"Russell" <rjshaw@iprimus.com.au> schrieb im Newsbeitrag news:3DA501C5.DE008F33@iprimus.com.au... > I gave up on doing any fpga design after wasting weeks on discovering > how broken floor planning with RPMs in 4.2i was, and there's no way i > can do without manual floorplanning. Altera had even less options and > the devices had no SRL16 equivalent. If 5.1i is no good, i'll start > investigating the cyclone devices. It would be good having a tool > that runs on linux too (wonder if i still need that leonardo with > the crappy gui bugs?). I was hoping 5.1i would fix everything, but > i haven't tried it yet. I think in many cases it is better to stay with the "old" software and handle the KNOWN bugs, instead of switching to new software with UNKOWN bugs. Yes, we all are unpaid BETA testers, but if you can avoid this, you better should do so. How many people REALLY need the new features (what are they?) of 5.1?? Up to now, I dont. So I will not change, especially not while a project is running. -- MfG FalkArticle: 48066
"MikeJ" <pacman@fpgaarcade.com> schrieb im Newsbeitrag news:1034206876.91304.0@dyke.uk.clara.net... > www.fpgaarcade.com update. > > Now include Space Invaders & Galaxian piccy links Last time I visited you page, there was just the VHDL archiev. And the statement, that you will not supply the ROMs. :-(( Can't you give at least a link to a ROM?? And maybe a short documentation of the stuff around the FPGA (VGS connection, Joystick etc) would be nice. -- MfG FalkArticle: 48067
"Ken Mac" <aeu96186@yahoo.co.uk> schrieb im Newsbeitrag news:ao45re$i5q$1@dennis.cc.strath.ac.uk... > > Ok - I'd better do a bit of a rethink and use a RESET signal in that case! If you need this reset only for a controlled power up reset (no reset during operation), you should use a ROC buffer, which delivers a Reset On Configuration. Have a look at the documentation about ROCBUF. -- MfG FalkArticle: 48068
At least with Synplify, initialization values seem to be retained in
synthesis. The following code works:
----------------------------------------------------------------------------
-----------
architecture rtl of Fifo is
signal Logic0 : std_logic := '0';
signal Logic1 : std_logic := '1';
begin
bram_gen:
for i in 0 to 7 generate
bram: RAMB4_S4_S4 port map (
ADDRA => ReadAddr,
ADDRB => WriteAddr,
DIB => WriteData(4*i+3 downto 4*i),
DIA => Logic0Bus,
WEA => Logic0,
WEB => WriteEnable,
CLKA => Clock,
CLKB => Clock,
RSTA => Logic0,
RSTB => Logic0,
ENA => Logic1,
ENB => Logic1,
DOA => ReadData(4*i+3 downto 4*i),
DOB => open
);
end generate bram_gen;
---------------------------------------------------------------------------
Barry Brown
"Ulises Hernandez" <ulises@britain.agilent.com> wrote in message
news:1034261597.151867@cswreg.cos.agilent.com...
> Hi Ken,
>
> The initialisation value assigned to a signal when it is defined (signal
> global_rst: std_logic;) is ignored during synthesis.
> It's valid for simulation only and most of today's synthesis tools will
flag
> that as a WARNING and just ignore it.
>
> Regards
>
> --
> Ulises Hernandez
> Design Engineer
> ECS Technology Limited
> ulisesh@ecs-tech.com
>
>
> "Ken Mac" <aeu96186@yahoo.co.uk> wrote in message
> news:ao3uc8$gb1$1@dennis.cc.strath.ac.uk...
> >
> > Hello,
> >
> > Hopefully an easy question:
> >
> > If I have a single bit signal that is initialised to either 0 or 1 such
> as:
> >
> > signal INIT : std_logic := '1';
> >
> > how exactly is this initialised into a slice?
> >
> > I assume it ends up as the output of one of the flip-flops but is it set
> > directly into the RAM cell of the flip-flop by the bitstream or does it
go
> > into the LUT and is then clocked into the flip-flop - or is it set by so
me
> > other means?
> >
> > I had a look on google groups and found some posts but they don't seem
to
> > describe how the value is actually set from the bitstream.
> >
> > Thanks for your time.
> >
> > Ken
> >
> >
>
>
Article: 48069
Bret, I am aware of the routing with hard macros, but I thought that routed hard macros got pinned to a
particular location. Anyway, the fact that it is outside of the normal flow makes design verification a
bear to deal with, as you point out.
Is there some documentation on this 'directed routing' for RPMs? I wasn't aware of any way of directing
the routing other than with the FPGA editor-> hard macro route.
Bret Wade wrote:
> Hello Ray,
>
> Hard macros (.nmc) can indeed contain routing information, but this is functionality is not often
> used. Here's a brief description of hard macro use cases:
>
> 1. Unplaced and unrouted hard macros - The macro is used to define only the component configuration
> and PAR is free to place and route as needed.
>
> 2. Placed and unrouted hard macros - The macro defines the component configuration and relative
> placement of the components. The router is free to route the macro as needed.
>
> 3. Placed and routed hard macros - The macro defines the component configuration, relative placement
> and routing of the macro.
>
> The problem with hard macros is that they exist only as a black box in the logical design so they
> complicate timing analysis and simulation. A combination of RPMs with Directed Routing contains the
> same functionality without this limitation. For that reason, hard macros tend to be used only as
> work arounds to force implementations that map/par can't handle.
>
> Regards,
> Bret
>
> Ray Andraka wrote:
>
> > some clarification:
> >
> > The hard macros don't exactly guarantee much more than an RPM does, as they also do not lock
> > down the routing. What it does do is lock down the pins of the LUTs, which will serve to bias
> > the router to use similar routing. However, if you have additional routes through the area, it
> > can make routing harder and can actually degrade the timing when compared to a regular RPM. We
> > used to be able to assign the pins to the lut back in the XACT days, but that capability
> > dissappeared with the M.1 tools. You can still trick it into using specific pins with some
> > limitations by replacing the LUTs with SRL16's and holding the WE input inactive for those cases
> > where you want to lock down LUT pins. Again, I try to avoid this low level, especially since it
> > obfuscates the code and can hamstring the router.
> >
> > Ray Andraka wrote:
> >
> > > I try to avoid doing hard macros, rather I stick to RPMs because they work better with the
> > > conventional tool flow. In the past, the router has done a pretty good job in most cases if
> > > the placement was good, so I rarely found the need to do hard macros other than as a
> > > work-around. 4.2i does not do as good a job of finding a good routing solution given a good
> > > placement, which means that there is more to gain from doing hard macros. I haven't had a
> > > chance to evaluate 5.1's routing yet, but I suspect the finish sooner mentality has only
> > > made the routing less optimal.
> > >
> > > Russell wrote:
> > >
> > > > My designs just use cascades of fairly repetitive filter and delay blocks
> > > > which is well suited to macro methods, and they're controlled with some
> > > > state-machine random logic. It should fit in the larger spartan devices.
> > > >
> > > > I heard that 4.2i fpga editor had bugs where vcc-gnd shorts happened.
> > > > Is the 5.1i fpga editor much better? Are hard macros relatively bug-free
> > > > to generate and use in 5.1i?
> > > >
> > > > Ray Andraka wrote:
> > > > >
> > > > > Bad news on 5.1. RPMs slow the mapping waaay down, at least big RPMs do. See my
> > > > > previous post. I haven't tried the floorplanner in 5.1 yet.
> > > > >
> > > > > 4.2i's floorplanner has a workaround if your design will go through PAR without a
> > > > > floorplan, you can then go into the floorplanner do a constrain from placement on your
> > > > > RPMs, then unbind, then rebind each RPM, then you can move them around. Of course, it
> > > > > does no good if your design won't make it through PAR without a floorplan, and it
> > > > > doesn't leave much room to move things around if youve got a dense device.
> > > > >
> > > > > I've more or less had to use RLOC_ORIGIN constraints in the UCF to take care of
> > > > > floorplanning RPMs under 4.2. I don't like it, but at least it is possible (reminds
> > > > > me too much of the days before the introduction of the floorplanner in XACT.
> > > > >
> > > > > Russell wrote:
> > > > >
> > > > > > I gave up on doing any fpga design after wasting weeks on discovering
> > > > > > how broken floor planning with RPMs in 4.2i was, and there's no way i
> > > > > > can do without manual floorplanning. Altera had even less options and
> > > > > > the devices had no SRL16 equivalent. If 5.1i is no good, i'll start
> > > > > > investigating the cyclone devices. It would be good having a tool
> > > > > > that runs on linux too (wonder if i still need that leonardo with
> > > > > > the crappy gui bugs?). I was hoping 5.1i would fix everything, but
> > > > > > i haven't tried it yet.
> > > > > >
> > > > > > Ray Andraka wrote:
> > > > > > >
> > > > > > > Same way we did before there was a floorplanner GUI: RLOCs and graph paper. How
> > > > > > > do you floorplan with the broken floorplanner GUI in 4.2i?
> > > > > > >
> > > > > > > Russell wrote:
> > > > > > >
> > > > > > > >
> > > > > > > > How do you floor-plan without a gui?
> > >
> > > --
> > > --Ray Andraka, P.E.
> > > President, the Andraka Consulting Group, Inc.
> > > 401/884-7930 Fax 401/884-7950
> > > email ray@andraka.com
> > > http://www.andraka.com
> > >
> > > "They that give up essential liberty to obtain a little
> > > temporary safety deserve neither liberty nor safety."
> > > -Benjamin Franklin, 1759
> >
> > --
> > --Ray Andraka, P.E.
> > President, the Andraka Consulting Group, Inc.
> > 401/884-7930 Fax 401/884-7950
> > email ray@andraka.com
> > http://www.andraka.com
> >
> > "They that give up essential liberty to obtain a little
> > temporary safety deserve neither liberty nor safety."
> > -Benjamin Franklin, 1759
--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com
"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
Article: 48070
Falk,
I'd be happy to stick with the 'old' tools, unfortunately we get pulled along
by both the customer and Xilinx. I still use 3.3sp8 for virtex and virtexE
designs because it works. In order to do so,however, I had to upgrade to the
timing files for virtexE that were released after 4.1 was. Xilinx doesn't see
fit to make the timing for 3.3sp8 available on the website, so you need to beg
your FAE for them (this, as far as I am concerned is a sin, especially since
those timing files are less optimistic than previous ones which means designs
done with the old files may not meet timing in real life...Xilinx, you
listening? The latest speed files should be made readily available for 3.3 at
a minimum because of the functional problems with later software releases).
We've hit some bugs in 4.2 that are show stoppers, and which are apparently
going to force us into 5.1 for the virtexII (3.3 doesn't support several
virtexII features, so you are forced to use 4.x or later). Of course 5.1
introduces new bugs, so we are in limp mode until we get a suitable combination
of tools working.
Falk Brunner wrote:
> "Russell" <rjshaw@iprimus.com.au> schrieb im Newsbeitrag
> news:3DA501C5.DE008F33@iprimus.com.au...
> > I gave up on doing any fpga design after wasting weeks on discovering
> > how broken floor planning with RPMs in 4.2i was, and there's no way i
> > can do without manual floorplanning. Altera had even less options and
> > the devices had no SRL16 equivalent. If 5.1i is no good, i'll start
> > investigating the cyclone devices. It would be good having a tool
> > that runs on linux too (wonder if i still need that leonardo with
> > the crappy gui bugs?). I was hoping 5.1i would fix everything, but
> > i haven't tried it yet.
>
> I think in many cases it is better to stay with the "old" software and
> handle the KNOWN bugs, instead of switching to new software with UNKOWN
> bugs. Yes, we all are unpaid BETA testers, but if you can avoid this, you
> better should do so. How many people REALLY need the new features (what are
> they?) of 5.1??
> Up to now, I dont. So I will not change, especially not while a project is
> running.
>
> --
> MfG
> Falk
--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com
"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
Article: 48071
You can indeed put an initialization on the flip-flops. Synplicity will
automatically put the attribute on the inferred flip-flop if the global reset
sets that flip-flop. If you instantiate flip-flops, the FDSE, FDS types will
default to initial 1, others to '0'. You can change that by adding an INIT=
attribute:
attribute INIT of FF0: label is "S"; to set, or
attribute INIT of FF0: label is "R"; to clear
these attach the appropriate attribute string tothe flip-flop primitive in the
edif file. To make simulation match the hardware, you also need to set/reset the
INIT generic to match.
Martin Kellermann wrote:
> Hi Ken,
>
> what Ulises said is correct, if you only put a init-value onto a signal
> then it will be ignored.
> However as you know the flipflops do not start up in a random state but
> on a defined value. The default-value would be '0' but you can set a
> differnt value via the UCF-file or via an attribute in your VHDL. That's
> what you do in the tools.
> In hardware the init-values are part of the bit-stream and are loaded
> during configuration. When you download the bit-stream the flipflops
> (and BTW all the other bits and pieces of the device) get the
> information what they have to do when the device is configured. Means
> all the bits of the bitstream are written into the appropriate locations
> and when your DONE-pin goes high and GSR (global set reset) is
> de-asserted you have an FPGA with the configuration you described in
> your VHDL/etc.
> So you don't have to clock e.g. bits from LUTs into FFs or something
> like that.
>
> Hope that helps,
>
> Martin
>
> Ken Mac wrote:
>
> > Hello,
> >
> > Hopefully an easy question:
> >
> > If I have a single bit signal that is initialised to either 0 or 1 such as:
> >
> > signal INIT : std_logic := '1';
> >
> > how exactly is this initialised into a slice?
> >
> > I assume it ends up as the output of one of the flip-flops but is it set
> > directly into the RAM cell of the flip-flop by the bitstream or does it go
> > into the LUT and is then clocked into the flip-flop - or is it set by some
> > other means?
> >
> > I had a look on google groups and found some posts but they don't seem to
> > describe how the value is actually set from the bitstream.
> >
> > Thanks for your time.
> >
> > Ken
> >
> >
> >
--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com
"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
Article: 48072Hi, sorry documentation is a bit light. I have drawn an example circuit that I will stick up shortly. It's been a bit busy this week ! I can't help you with the rom images, although many software emulator sites have them. I am also working on some tools that will convert a binary file to xilinx block rams which will help. (there is a almost suitable sw tool on opencore.org / risc5x I think) Cheers MikeJ "Falk Brunner" <Falk.Brunner@gmx.de> wrote in message news:ao49ha$iq965$3@ID-84877.news.dfncis.de... > "MikeJ" <pacman@fpgaarcade.com> schrieb im Newsbeitrag > news:1034206876.91304.0@dyke.uk.clara.net... > > www.fpgaarcade.com update. > > > > Now include Space Invaders & Galaxian piccy links > > Last time I visited you page, there was just the VHDL archiev. And the > statement, that you will not supply the ROMs. :-(( Can't you give at least > a link to a ROM?? And maybe a short documentation of the stuff around the > FPGA (VGS connection, Joystick etc) would be nice. > > -- > MfG > Falk > > > > > >Article: 48073
I think that someone here said they were looking for one of these Spartan II devices in a large quantity. Just a note to say that we have excess of both devices (a few hundred of each).Article: 48074
Falk Brunner wrote: >>Xilinx tools are not interesting, they don't need to be. Many designers >>never even run up the gui. The simulator is where the action is. > From which planet are you from? I think I live nearby. Time is more limited than gates. 90% sim, 5% synth, 5% p+r -- 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