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
>With FPGAs increasing in size at roughly the same Moore's Law rate, and similar >performance increases, the end result is that "surprisingly efficient circuits from nearly >arbitrary C" is more than good enough to replace VHDL/Verilog for the majority of >algorithmic and systems level designs to allow faster time to market, with a larger pool >of talent (being able to draw on C coders), with good enough performance and fit so >that expensive fine tuning and coding in VHDL/Verilog will NOT be required. Wow, that's a long sentence :) and one I broadly agree with. I'm not so sure about the phrase "nearly arbitrary C". I don't know all the tools though, so I'm presenting my limited experiences here, not what I think is universally true... So no flaming. :) Is there any tool out there that can produce code that rivals good VHDL when written by a "C coder"? I'm currently working with a very bright undergrad who has never used VHDL before, and I've got them using a C-to-VHDL tool. To effectively use the tool, they're having to understand why they need shortcuts that avoid "/, % and *" as much as possible. They need to think about memory management in a very new way, in a land where BRAM is not limitless. They're also having to consider the differences between BRAM, SRAM and registered values and their effects on performance. They need to understand what will break the pipeline and what won't, what will result in big pipeline latency and what won't. They need explanations as to why a few small changes can quarter the final slice count. To work effectively you need to understand what kind of hardware that you are inferring by what you write. Two functionally equivalent statements can compile to two very different VHDL projects. In my experience, HLLs free you up from the drudgeries of HDLs, but they don't yet free you up from the need for an understanding of the underlying hardware. With nothing but a C knowledge you can get something big and slow, but for small and fast, you need to know what you're inferring. Cheers, RobinArticle: 91376
Does anybody knows why does the Icarus Verilog disapeared? MehdiArticle: 91377
GaLaKtIkUs™ wrote: > Does anybody knows why does the Icarus Verilog disapeared? > > Mehdi > Not sure! As for me , I would *never* use a synthesizer that was not supported in some way for any serious. Not to trash the hard work that was put into Icarus Verilog. Its hard enough trying to track down my own bugs, let alone somebody elses. Some things are worth paying for a *team* of engineers to do. That being said, having free tools are nice. But this is a non-issue now. I think just about all of the major vendors give away versions that are tools that will cover quite large applications. I think the open source part is a non-issue. There is almost nothing that most can do to optimize the synthesis algorithms. At best, you'll match what Synplicity, etc. have already done. And if you add up the time trying to get there, its not worth it. You might as well put that same amount of time running a lemonade stand and then buy a copy of commercial synthesizer with the profits. Either way your out 4000 Man-hours, but with one latter option you'll end up with a better product and support! If you feel you can optimize a piece of HDL better, you'll just implement your design by instantiating gate level primitives! And if you are even more motivated, join the synplicity, Xilinx, etc. team! Just my thoughts... -EliArticle: 91378
Robin Bruce wrote: >Two functionally equivalent statements can compile to two very > different VHDL projects. In my experience, HLLs free you up from the > drudgeries of HDLs, but they don't yet free you up from the need for an > understanding of the underlying hardware. With nothing but a C > knowledge you can get something big and slow, but for small and fast, > you need to know what you're inferring. That's a clear problem, even with C coders and doing any kind of device driver on a traditional system. The pool of C coders that understand hardware enough to write drivers is a small percentage of actual coders. The difference is that it's relatively easy to teach the high level aspects of hardware from a systems perspective to train new device driver writers and maintainers, and one good low level engineer can mentor some half dozen others with less skill and maintain the quality level necessary for production work. I've done so on several cross architecture porting projects with undergrad students. I believe there is a similar leverage in using C coders for FPGA work, you do not need EE's with logic level design skills to develop fpga projects, but you do need to teach C coders about the hardware architecture models that the HLL is going to produce after synthesis. Even today it's necessary to teach C coders about cycle counting, as assembly language coding is no longer a basic skill. Performance sensitive designs require teaching about working sets, cache performance issues, CPU pipelines, and a number of issues that a typical C++ or other object oriented coder remains clueless about. There is a continuous design space: BitLevelLogic<===============================>AbstractAlgorithms Schematic designs on the left, VHDL/Verilog somewhere left of center, C based HLLs somewhere just right of center, with better HLLs to come even farther right of center. EE's tend to design to the left of center, and HLL coders to the right of center under this model, and the better the HLL effieciently hides the hardware, the farther to the right we move. So the bottom line, is that just as EE's were the entire computer development staff in the 50's, today EE's are a fraction of the product development team. With FPGAs becoming common along with HLLs we will see that same trend. During the 70's we saw a lot of old salt EE's and Systems types crying about HLLs and computer performance, which is nearly a moot point today. Ditto for EE's and systems types that will be crying about large commodity FPGAs similarly not being effieciently used by HLLs generating FPGA designs from abstract language tools.Article: 91379
Antti Lukats wrote: > After loooong waiting the CoreConsole tool can now be downloaded from Actgel > website. > It allows to create ARM based SoCs for the PA3/E Flash FPGA's. > > Current version doesnt yet allow creation of custom peripherals what is > promised in next releas(es). > Also the distributors (at least in Gemany) do not have and ARM7 ready > silicon to ship from stock. > On my email inquiry I was asked to call back. I called and asked my question > again > "do have some silicon to ship" what as usual ended up in long discusssion > what is what I need > why I need it, do I want support. My question about availability remained > unanswered still. > > Anyway its some progress... Actel has been trying to push their ARM7 for > some time > without the actual support for it in the tools available, now the software > supports at > least seems to be avaialble. > > Antti > DIY - FPGA Logic Analyzer: > http://cgi.ebay.de/ws/eBayISAPI.dll?ViewItem&item=5826253867 > > I have been very interested in the Actel parts. The built in FLASH for configuration is very interesting. I wish Xilinx would do this!!! I am actually considering buying their dev kit. Having the integrated FLASH is so nice. especially after all the headache I went through to buy Platform Flash devices (before they were available on the Xilinx estore). -ELiArticle: 91380
Robin Bruce wrote: > I can safely say that DIME-C is to all intents and > purposes a subset of C, so everything you do in it can be compiled with > a gcc compiler. You can't have pointers, and you have to go round the > houses sometimes to avoid breaking your pipelines, but it's definitely > recognisable as C. If anyone is particularly interested, I could send > them some examples of the code. Simple code examples and synthesis results is what is missing from the web sites and discussions I have seen. If you've got some, consider posting a link so that all interested can have a look. -- Mike TreselerArticle: 91381
GaLaKtIkUs™ wrote: > So no problem with ChipScope? I can Buy the DO-SPAR3-DK board and use > the ChipScope and the PC4 cable (availlable in our university's lab) ? > Yes, I have used ChipScope Pro with that board and with both parallel cables (version 3 and version 4). Here is my only warning, if you have the USB JTag cable, make sure you do not have old parallel cables plugged into the PC at the same time. -EliArticle: 91382
Robin Bruce wrote: > I'm a research engineer > based in Nallatech, and I've been working with a tool being developed > there, DIME-C. For those that haven't looked at this stuff, it's the next generation HLL FPGA environment, two steps above C with a cute GUI based system level abstraction tool .... very cool :) http://www.nallatech.com/mediaLibrary/images/english/4063.pdfArticle: 91383
On a sunny day (Fri, 04 Nov 2005 10:42:26 -0500) it happened Eli Hughes <emh203@psu.edu> wrote in <dkfvh2$11l0$1@f04n12.cac.psu.edu>: >GaLaKtIkUs™ wrote: >> Does anybody knows why does the Icarus Verilog disapeared? >> >> Mehdi >> > > >Not sure! As for me , I would *never* use a synthesizer that was not >supported in some way for any serious. Not to trash the hard work that >was put into Icarus Verilog. Its hard enough trying to track down my own >bugs, let alone somebody elses. I think iverilog is a very useful verilog compiler. And fast. _________________________________________ Usenet Zone Free Binaries Usenet Server More than 140,000 groups Unlimited download http://www.usenetzone.com to open accountArticle: 91384
Hi John_H,
I stand corrected.
You are right that Xilinx did get PCILOGIC back in Spartan-3E.
I was sort of skeptical because I always thought that Xilinx no longer
needed PCILOGIC because FPGAs have gotten so much faster, but I still
ran the following Verilog design instantiating PCILOGIC.
________________________
module PCILOGIC_Test (
IRDY,
TRDY,
I1,
I2,
I3,
PCI_CE
);
inout IRDY;
inout TRDY;
input I1;
input I2;
input I3;
output PCI_CE;
PCILOGIC MAGICBOX (
.IRDY(IRDY),
.TRDY(TRDY),
.I1(I1),
.I2(I2),
.I3(I3),
.PCI_CE(PCI_CE)
);
endmodule
module PCILOGIC (
IRDY,
TRDY,
I1,
I2,
I3,
PCI_CE
);
input IRDY;
input TRDY;
input I1;
input I2;
input I3;
output PCI_CE;
endmodule
________________________
And here is what I got.
________________________
Release 7.1.04i Map H.42
Xilinx Mapping Report File for Design 'PCILOGIC_Test'
Design Information
------------------
Command Line : C:/Xilinx/bin/nt/map.exe -ise
c:\pcilogic\spartan_3e\PCILOGIC.ise -intstyle ise -p xc3s250e-pq208-4
-cm area -pr b -k 4 -c 100 -o PCILOGIC_Test_map.ncd PCILOGIC_Test.ngd
PCILOGIC_Test.pcf
Target Device : xc3s250e
Target Package : pq208
Target Speed : -4
Mapper Version : spartan3e -- $Revision: 1.26.6.4 $
Mapped Date : Fri Nov 04 09:53:03 2005
Design Summary
--------------
Number of errors: 0
Number of warnings: 2
Logic Utilization:
Logic Distribution:
Number of Slices containing only related logic: 0 out of
0 0%
Number of Slices containing unrelated logic: 0 out of
0 0%
*See NOTES below for an explanation of the effects of unrelated logic
Number of bonded IOBs: 6 out of 158 3%
Number of PCILOGICSEs: 1 out of 2 50%
Total equivalent gate count for design: 0
Additional JTAG gate count for IOBs: 288
Peak Memory Usage: 112 MB
NOTES:
Related logic is defined as being logic that shares connectivity -
e.g. two
LUTs are "related" if they share common inputs. When assembling slices,
Map gives priority to combine logic that is related. Doing so
results in
the best timing performance.
Unrelated logic shares no connectivity. Map will only begin packing
unrelated logic into a slice once 99% of the slices are occupied through
related logic packing.
Note that once logic distribution reaches the 99% level through related
logic packing, this does not mean the device is completely utilized.
Unrelated logic packing will then begin, continuing until all usable
LUTs
and FFs are occupied. Depending on your timing budget, increased
levels of
unrelated logic packing may adversely affect the overall timing
performance
of your design.
Table of Contents
-----------------
Section 1 - Errors
Section 2 - Warnings
Section 3 - Informational
Section 4 - Removed Logic Summary
Section 5 - Removed Logic
Section 6 - IOB Properties
Section 7 - RPMs
Section 8 - Guide Report
Section 9 - Area Group Summary
Section 10 - Modular Design Summary
Section 11 - Timing Report
Section 12 - Configuration String Information
Section 13 - Additional Device Resource Counts
Section 1 - Errors
------------------
Section 2 - Warnings
--------------------
WARNING:PhysDesignRules:367 - The signal <TRDY_IBUF_FANOUT> is
incomplete. The
signal does not drive any load pins in the design.
WARNING:PhysDesignRules:367 - The signal <IRDY_IBUF_FANOUT> is
incomplete. The
signal does not drive any load pins in the design.
Section 3 - Informational
-------------------------
INFO:LIT:244 - All of the single ended outputs in this design are using slew
rate limited output drivers. The delay on speed critical single
ended outputs
can be dramatically reduced by designating them as fast outputs in the
schematic.
Section 4 - Removed Logic Summary
---------------------------------
Section 5 - Removed Logic
-------------------------
Section 6 - IOB Properties
--------------------------
+-----------------------------------------------------------------------------------------------------------------------------------------+
| IOB Name | IOB Type | Direction | IO
Standard | Drive | Slew | Reg (s) | Resistor | IBUF/IFD |
| | | |
| Strength | Rate | | | Delay |
+-----------------------------------------------------------------------------------------------------------------------------------------+
| I1 | IBUF | INPUT |
LVCMOS25 | | | | | 0 / 0 |
| I2 | IBUF | INPUT |
LVCMOS25 | | | | | 0 / 0 |
| I3 | IBUF | INPUT |
LVCMOS25 | | | | | 0 / 0 |
| IRDY | IBUF | INPUT |
LVCMOS25 | | | | | 0 / 0 |
| PCI_CE | IOB | OUTPUT |
LVCMOS25 | 12 | SLOW | | | 0 / 0 |
| TRDY | IBUF | INPUT |
LVCMOS25 | | | | | 0 / 0 |
+-----------------------------------------------------------------------------------------------------------------------------------------+
Section 7 - RPMs
----------------
Section 8 - Guide Report
------------------------
Guide not run on this design.
Section 9 - Area Group Summary
------------------------------
No area groups were found in this design.
Section 10 - Modular Design Summary
-----------------------------------
Modular Design not used for this design.
Section 11 - Timing Report
--------------------------
This design was not run using timing mode.
Section 12 - Configuration String Details
--------------------------
Use the "-detail" map option to print out Configuration Strings
Section 13 - Additional Device Resource Counts
----------------------------------------------
Number of JTAG Gates for IOBs = 6
Number of Equivalent Gates for Design = 0
Number of RPM Macros = 0
Number of Hard Macros = 0
STARTUP_SPARTAN3E = 0
PCILOGICSE = 1
MULT18X18SIO = 0
DCIRESETs = 0
CAPTUREs = 0
BSCANs = 0
STARTUPs = 0
DCMs = 0
GCLKs = 0
ICAPs = 0
18X18 Multipliers = 0
Block RAMs = 0
IOB Master Pads = 0
IOB Slave Pads = 0
IOB ODDR2 = 0
IOB IDDR2 = 0
IOB Regular Flip Flops not driven by LUTs = 0
IOB Regular Flip Flops = 0
IOB Latches not driven by LUTs = 0
IOB Latches = 0
Unbonded IOBs = 0
Bonded IOBs = 6
XORs = 0
CARRY_INITs = 0
CARRY_SKIPs = 0
CARRY_MUXes = 0
Shift Registers = 0
Static Shift Registers = 0
Dynamic Shift Registers = 0
16x1 ROMs = 0
16x1 RAMs = 0
32x1 RAMs = 0
Dual Port RAMs = 0
MUXFs = 0
MULT_ANDs = 0
4 input LUTs used as Route-Thrus = 0
4 input LUTs = 0
Slice Latches not driven by LUTs = 0
Slice Latches = 0
Slice Flip Flops not driven by LUTs = 0
Slice Flip Flops = 0
SliceMs = 0
SliceLs = 0
Slices = 0
F6 Muxes = 0
F5 Muxes = 0
F8 Muxes = 0
F7 Muxes = 0
Number of LUT signals with 4 loads = 0
Number of LUT signals with 3 loads = 0
Number of LUT signals with 2 loads = 0
Number of LUT signals with 1 load = 0
NGM Average fanout of LUT = -1.#J
NGM Maximum fanout of LUT = 0
NGM Average fanin for LUT = -1.#IND
________________________
I guess PCILOGIC is now called PCILOGICSE. (PCILOGIC Second Edition?
PCILOGIC S(partan-3)E?)
Kevin Brace
John_H wrote:
> "Kevin Brace" <sa0les1@brac2ed3esi4gns5olut6ions.com> wrote in message
> news:lJ8af.3419$Lv.658@newssvr23.news.prodigy.net...
> <snip>
>
>>... but as many already know, it is supported by Virtex, Virtex-E,
>>Spartan-II, and Spartan-IIE only.
>>Xilinx dropped the support of PCILOGIC starting in Virtex-II.
>
> <snip>
>
> But they brought it back in Spartan-3E !
>
>
--
Brace Design Solutions
Xilinx (TM) LogiCORE (TM) PCI compatible BDS XPCI PCI IP core available
for as little as $100 for non-commercial, non-profit, personal use.
http://www.bracedesignsolutions.com
Xilinx and LogiCORE are registered trademarks of Xilinx, Inc.
Article: 91385I don't use the iverilog for synthesis - however I *do* use it for rtl simulation - since I can't find other free simulators to run on Linux - and for hobby projects (even large ones) it is quite good imho. A pity if it disappeared completely - time for making a fresh backup of the current source tree on my HDD - I'd be quite stuck without it ;) -- Brian Eli Hughes wrote: > GaLaKtIkUs™ wrote: > >> Does anybody knows why does the Icarus Verilog disapeared? >> >> Mehdi >> > > > Not sure! As for me , I would *never* use a synthesizer that was not > supported in some way for any serious. Not to trash the hard work that > was put into Icarus Verilog. Its hard enough trying to track down my own > bugs, let alone somebody elses. > > Some things are worth paying for a *team* of engineers to do. > > That being said, having free tools are nice. But this is a non-issue > now. I think just about all of the major vendors give away versions > that are tools that will cover quite large applications. I think the > open source part is a non-issue. There is almost nothing that most can > do to optimize the synthesis algorithms. At best, you'll match what > Synplicity, etc. have already done. And if you add up the time trying > to get there, its not worth it. You might as well put that same amount > of time running a lemonade stand and then buy a copy of commercial > synthesizer with the profits. Either way your out 4000 Man-hours, but > with one latter option you'll end up with a better product and support! > > If you feel you can optimize a piece of HDL better, you'll just > implement your design by instantiating gate level primitives! And if > you are even more motivated, join the synplicity, Xilinx, etc. team! > > Just my thoughts... > > -EliArticle: 91386
Hi Jan, Although I understand the usual "your mileage may vary," but recently I spent two days trying to run a PCI IP core (Xilinx LogiCORE PCI compatible BDS XPCI PCI IP core) I developed with IVI (Icarus Verilog Interactive). The binary of IVI I used was ivi-0.4-pre-20031121-setup.exe from sourceforge.net (http://sourceforge.net/project/showfiles.php?group_id=53425), the last version without Eclipse. The reason I picked IVI instead of the regular Icarus Verilog was that I have not been successful running Icarus Verilog from Windows 2000's Command Prompt, and also Icarus Verilog doesn't come with GUI. Because of the low expectations people have of free EDA tools, I honestly didn't think IVI can run BDS XPCI PCI IP core along with the simulation model of Xilinx LogiCORE PCI, but it somehow did finish the simulation. Wow, that's not bad, it beat my very low expectations. The simulation speed of IVI was okay if not great for me, but the biggest problem of IVI (and perhaps Icarus Verilog) was that the compilation and loading of the entire design was soooooo slow that it probably will make it useless for most people to use as an HDL simulator. Maybe the more recent version of Icarus Verilog might be better, but I have not been able to run IVI with Eclipse. (Took three days to figure out how to install it, and it crashes when I try to run it.) Kevin Brace Jan Panteltje wrote: > On a sunny day (Fri, 04 Nov 2005 10:42:26 -0500) it happened Eli Hughes > <emh203@psu.edu> wrote in <dkfvh2$11l0$1@f04n12.cac.psu.edu>: > > >>GaLaKtIkUs™ wrote: >> >>>Does anybody knows why does the Icarus Verilog disapeared? >>> >>>Mehdi >>> >> >> >>Not sure! As for me , I would *never* use a synthesizer that was not >>supported in some way for any serious. Not to trash the hard work that >>was put into Icarus Verilog. Its hard enough trying to track down my own >>bugs, let alone somebody elses. > > > I think iverilog is a very useful verilog compiler. > And fast. > _________________________________________ > Usenet Zone Free Binaries Usenet Server > More than 140,000 groups > Unlimited download > http://www.usenetzone.com to open account -- Brace Design Solutions Xilinx (TM) LogiCORE (TM) PCI compatible BDS XPCI PCI IP core available for as little as $100 for non-commercial, non-profit, personal use. http://www.bracedesignsolutions.com Xilinx and LogiCORE are registered trademarks of Xilinx, Inc.Article: 91387
Here's a quick tutorial of using two PowerPC's..However there are few things that need to be fixed in the document below..But I am assuming that u can do it...I did this and modified few things and it worked.... http://www.cse.ucsc.edu/~rios/ml310/dual_core.htm -- ParagArticle: 91388
GaLaKtIkUs=99 wrote: > Does anybody knows why does the Icarus Verilog disapeared? > > Mehdi It looks like the main site is gone/crashed/dead for today. But the nice part about GPL'd stuff is that it will always be available somewhere, if not on sourceforge. see http://www.geda.seul.org/tools/icarus/ where it's embedded in the gEDA project, and is likely to maintained there if the author has given up on it.Article: 91389
Kevin Brace wrote:
> I am myself surprised that the use of MUX inside the BDS XPCI PCI IP
> core reduced the LUT this much, but what is interesting is that trying
> to emulate internal tri-state buffer with LUTs increases the LUT usage
> quite a bit.
Good to see some actual evidence
on this often debated topic.
Thanks for the posting.
-- Mike Treseler
Article: 91390Brian Dam Pedersen <brian.pedersen@mail.danbbs.dk> wrote: > I don't use the iverilog for synthesis - however I *do* use it for rtl > simulation - since I can't find other free simulators to run on Linux - > and for hobby projects (even large ones) it is quite good imho. A pity > if it disappeared completely - time for making a fresh backup of the > current source tree on my HDD - I'd be quite stuck without it ;) I think Stephan is on some longer vacation, ast Stephan told on the gea mailing list october 8. It's natural that the website goes down in such a situation... The other option for a free simuator is http://www.pragmatic-c.com/ I am very glad about those two option. Bye -- Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------Article: 91391
Robin Bruce wrote: > Jim, > > Apologies for my ignorance, but can I ask you to expand on "alternative > of HLL -> FPGA Running HLL amd the best tool set". I wasn't sure what > you meant. Jim Granville wrote: >> The HLL -> HDL path, misses the alternative of HLL -> FPGA Running HLL >> amd the best tool set, will be one that allows a softer migration >> between Opcodes and Registers. "FPGA Running HLL" is a terse way of saying a SoftCPU (can be DSP enhanced) running opcodes (ex HLL), on the FPGA. ie a FPGA CPU eg NIOS has an interesting Opcode extension scheme - you can code in C, run in C, and then grab ONLY the tight stuff for expansion into hardware, and call with an opcode. The FPGA vendors seem to be favouring the 'sea of DSP' and std tool flows, over 'sea of programmers' approach :) -jgArticle: 91392
Hi, I had this error in Xilinx ISE 7.1 but I cannot understand why, or what
to do about it.
Any help appreciated.
Thanks,
-Andrew
Release 7.1.04i Map H.42
Xilinx Mapping Report File for Design 'xilinxchip_original'
Design Information
------------------
Command Line : C:/Xilinx/bin/nt/map.exe -ise
c:\xilinx\bin\pv4_004mfsd_127\original.ise -intstyle ise -p
xc4vlx60-ff668-12
-cm area -detail -pr b -k 4 -c 100 -o xilinxchip_original_map.ncd
xilinxchip_original.ngd xilinxchip_original.pcf
Target Device : xc4vlx60
Target Package : ff668
Target Speed : -12
Mapper Version : virtex4 -- $Revision: 1.26.6.4 $
Mapped Date : Sun Oct 30 23:20:44 2005
Design Summary
--------------
Number of errors : 1
Number of warnings :1132
Section 1 - Errors
------------------
ERROR:Pack:1142 - A problem was encountered updating the component types
within
the following shape:
The RPM "uChip0_Cal1_XA1_TA0/hset"
A problem was encountered trying to change the type of the component
containing the following symbols to "SLICEL".
LUT symbol "uChip0_Cal1_XA1_TA0/BU1006" (Output Signal =
uChip0_Cal1_XA1_TA0/N56436) (RLOC=X5Y10, Set=uChip0_Cal1_XA1_TA0/hset)
Shift symbol "uChip0_Cal1_XA1_TA0/BU1014" (Output Signal =
uChip0_Cal1_XA1_TA0/N56799) (RLOC=X5Y10, Set=uChip0_Cal1_XA1_TA0/hset)
FLOP symbol "uChip0_Cal1_XA1_TA0/BU1017" (Output Signal =
uChip0_Cal1_XA1_TA0/N720) (RLOC=X5Y10, Set=uChip0_Cal1_XA1_TA0/hset)
The component is already of type "SLICEM". The setting of the component
type
is necessary since it is an odd number of columns away from a component
which
already has a type of "SLICEM". This second component contains the
following
symbols:
Shift symbol "uChip0_Cal1_XA1_TA0/BU996" (Output Signal =
uChip0_Cal1_XA1_TA0/N56748) (RLOC=X4Y10, Set=uChip0_Cal1_XA1_TA0/hset)
FLOP symbol "uChip0_Cal1_XA1_TA0/BU999" (Output Signal =
uChip0_Cal1_XA1_TA0/N56731) (RLOC=X4Y10, Set=uChip0_Cal1_XA1_TA0/hset)
Shift symbol "uChip0_Cal1_XA1_TA0/BU1001" (Output Signal =
uChip0_Cal1_XA1_TA0/N56768) (RLOC=X4Y10, Set=uChip0_Cal1_XA1_TA0/hset)
FLOP symbol "uChip0_Cal1_XA1_TA0/BU1004" (Output Signal =
uChip0_Cal1_XA1_TA0/N56430) (RLOC=X4Y10, Set=uChip0_Cal1_XA1_TA0/hset)
This architecture has two types of components, SLICELs and SLICEMs, in
alternating columns. Only SLICEMs can contain RAM symbols.
Article: 91393"Andrew Lohbihler" <xyz.interactive@rogers.com> schrieb im Newsbeitrag news:TfCdndMvzOo2TPbenZ2dnUVZ_tGdnZ2d@rogers.com... > Hi, I had this error in Xilinx ISE 7.1 but I cannot understand why, or > what to do about it. > Any help appreciated. > Thanks, > -Andrew your desing requires for some reason SLICEMs to be placed at invalid relative positions. This is the error saying. Why it happens I can not tell, some problem with placement constraints. AnttiArticle: 91394
On a sunny day (Fri, 4 Nov 2005 20:29:18 +0000 (UTC)) it happened Uwe Bonnes <bon@hertz.ikp.physik.tu-darmstadt.de> wrote in <dkggau$slh$1@lnx107.hrz.tu-darmstadt.de>: >I think Stephan is on some longer vacation, ast Stephan told on the gea >mailing list october 8. It's natural that the website goes down in such a >situation... mmm, my server, runs Linux 24/7: panteltje:~# uptime 10:36pm up 52 days, 8:15, 7 users, load average: 0.20, 0.60, 1.44 It is pretty secure now with many bad guys in ipchains :-) _________________________________________ Usenet Zone Free Binaries Usenet Server More than 140,000 groups Unlimited download http://www.usenetzone.com to open accountArticle: 91395
Unlike earlier Virtex family devices, the Virtex-4 has half the slices allowed as memory-capable. The RPM cannot have shift registers or distributed CLB SelectRAM (single port or dual port) in both odd AND even RLOC columns. The SLICEL has a lookup table that's logic only while the SLICEM has LUTs that can be loaded and read as a single port memory, a dual-port memory, or a shift register. If the RPM was done for a project in a Virtex-IIPro or older device, you'll need to tweak it for the "odd or even column only" constraint of the Virtex-4. If your RPM is fresh for this design, simply reconfigure it for the constraint you now know is getting in your way. - John_H "Andrew Lohbihler" <xyz.interactive@rogers.com> wrote in message news:TfCdndMvzOo2TPbenZ2dnUVZ_tGdnZ2d@rogers.com... > Hi, I had this error in Xilinx ISE 7.1 but I cannot understand why, or > what to do about it. > Any help appreciated. > Thanks, > -Andrew > > > Release 7.1.04i Map H.42 > Xilinx Mapping Report File for Design 'xilinxchip_original' > > Design Information > ------------------ > Command Line : C:/Xilinx/bin/nt/map.exe -ise > c:\xilinx\bin\pv4_004mfsd_127\original.ise -intstyle ise -p > xc4vlx60-ff668-12 > -cm area -detail -pr b -k 4 -c 100 -o xilinxchip_original_map.ncd > xilinxchip_original.ngd xilinxchip_original.pcf > Target Device : xc4vlx60 > Target Package : ff668 > Target Speed : -12 > Mapper Version : virtex4 -- $Revision: 1.26.6.4 $ > Mapped Date : Sun Oct 30 23:20:44 2005 > > Design Summary > -------------- > Number of errors : 1 > Number of warnings :1132 > Section 1 - Errors > ------------------ > ERROR:Pack:1142 - A problem was encountered updating the component types > within > the following shape: > The RPM "uChip0_Cal1_XA1_TA0/hset" > A problem was encountered trying to change the type of the component > containing the following symbols to "SLICEL". > LUT symbol "uChip0_Cal1_XA1_TA0/BU1006" (Output Signal = > uChip0_Cal1_XA1_TA0/N56436) (RLOC=X5Y10, Set=uChip0_Cal1_XA1_TA0/hset) > Shift symbol "uChip0_Cal1_XA1_TA0/BU1014" (Output Signal = > uChip0_Cal1_XA1_TA0/N56799) (RLOC=X5Y10, Set=uChip0_Cal1_XA1_TA0/hset) > FLOP symbol "uChip0_Cal1_XA1_TA0/BU1017" (Output Signal = > uChip0_Cal1_XA1_TA0/N720) (RLOC=X5Y10, Set=uChip0_Cal1_XA1_TA0/hset) > The component is already of type "SLICEM". The setting of the component > type > is necessary since it is an odd number of columns away from a component > which > already has a type of "SLICEM". This second component contains the > following > symbols: > Shift symbol "uChip0_Cal1_XA1_TA0/BU996" (Output Signal = > uChip0_Cal1_XA1_TA0/N56748) (RLOC=X4Y10, Set=uChip0_Cal1_XA1_TA0/hset) > FLOP symbol "uChip0_Cal1_XA1_TA0/BU999" (Output Signal = > uChip0_Cal1_XA1_TA0/N56731) (RLOC=X4Y10, Set=uChip0_Cal1_XA1_TA0/hset) > Shift symbol "uChip0_Cal1_XA1_TA0/BU1001" (Output Signal = > uChip0_Cal1_XA1_TA0/N56768) (RLOC=X4Y10, Set=uChip0_Cal1_XA1_TA0/hset) > FLOP symbol "uChip0_Cal1_XA1_TA0/BU1004" (Output Signal = > uChip0_Cal1_XA1_TA0/N56430) (RLOC=X4Y10, Set=uChip0_Cal1_XA1_TA0/hset) > This architecture has two types of components, SLICELs and SLICEMs, in > alternating columns. Only SLICEMs can contain RAM symbols. >Article: 91396
Brian Dam Pedersen wrote: > I don't use the iverilog for synthesis - however I *do* use it for rtl > simulation - since I can't find other free simulators to run on Linux - > and for hobby projects (even large ones) it is quite good imho. A pity > if it disappeared completely - time for making a fresh backup of the > current source tree on my HDD - I'd be quite stuck without it ;) Exactly, and since the site is down I grabbed the latest from geda site, in the same way I grabbed Suse-10.0 from www.opensuse.org when I did read Novell had management changes, now I have latest Suse Linux with gcc4 for free.... I'd say get it while you can, it is only 3.5GB or so...Article: 91397
Guys, let's make a deal: I give you a bit more, more early, and more honest information than you can read in the press releases. You, in turn, stop molesting and attacking me whenever I write anything about dates and avilability. I am not in marketing, but I am reasonably honest, and I believe in what I write (or I just don't write about it.) Isn't that good enough? PeterArticle: 91398
Peter Alfke wrote: > Guys, let's make a deal: > I give you a bit more, more early, and more honest information than you > can read in the press releases. > You, in turn, stop molesting and attacking me whenever I write anything > about dates and avilability. > I am not in marketing, but I am reasonably honest, and I believe in > what I write (or I just don't write about it.) > Isn't that good enough? > Peter Sounds good to me. I don't think anyone attacks you, but there is a general grumble about the state of roll-out-slippage. ie ES devices really do sound like candidates for Webstore ? When a demo-PCB is as close as next month, then posting info on what's comming, will be generally appreciated. Everyone here can understand the PCB mfg cycles - often the paperwork approval takes longer : so posting a price, avail in XX weeks, helps everyone. -jgArticle: 91399
Thanks John, The code did work for a Virtex-II and the details of the packing don't indicate which column constraint was used. Any idea what constraint should be changed to make it work in a Virtex-4? There must be a way to tweak the design for the V4 to make it pack similarily as a V2. Any help will do. Thanks, Andrew "John_H" <johnhandwork@mail.com> wrote in message news:YMQaf.57$Ge6.296@news-west.eli.net... > Unlike earlier Virtex family devices, the Virtex-4 has half the slices > allowed as memory-capable. The RPM cannot have shift registers or > distributed CLB SelectRAM (single port or dual port) in both odd AND even > RLOC columns. The SLICEL has a lookup table that's logic only while the > SLICEM has LUTs that can be loaded and read as a single port memory, a > dual-port memory, or a shift register. > > If the RPM was done for a project in a Virtex-IIPro or older device, > you'll need to tweak it for the "odd or even column only" constraint of > the Virtex-4. If your RPM is fresh for this design, simply reconfigure it > for the constraint you now know is getting in your way. > > - John_H > > > "Andrew Lohbihler" <xyz.interactive@rogers.com> wrote in message > news:TfCdndMvzOo2TPbenZ2dnUVZ_tGdnZ2d@rogers.com... >> Hi, I had this error in Xilinx ISE 7.1 but I cannot understand why, or >> what to do about it. >> Any help appreciated. >> Thanks, >> -Andrew >> >> >> Release 7.1.04i Map H.42 >> Xilinx Mapping Report File for Design 'xilinxchip_original' >> >> Design Information >> ------------------ >> Command Line : C:/Xilinx/bin/nt/map.exe -ise >> c:\xilinx\bin\pv4_004mfsd_127\original.ise -intstyle ise -p >> xc4vlx60-ff668-12 >> -cm area -detail -pr b -k 4 -c 100 -o xilinxchip_original_map.ncd >> xilinxchip_original.ngd xilinxchip_original.pcf >> Target Device : xc4vlx60 >> Target Package : ff668 >> Target Speed : -12 >> Mapper Version : virtex4 -- $Revision: 1.26.6.4 $ >> Mapped Date : Sun Oct 30 23:20:44 2005 >> >> Design Summary >> -------------- >> Number of errors : 1 >> Number of warnings :1132 >> Section 1 - Errors >> ------------------ >> ERROR:Pack:1142 - A problem was encountered updating the component types >> within >> the following shape: >> The RPM "uChip0_Cal1_XA1_TA0/hset" >> A problem was encountered trying to change the type of the component >> containing the following symbols to "SLICEL". >> LUT symbol "uChip0_Cal1_XA1_TA0/BU1006" (Output Signal = >> uChip0_Cal1_XA1_TA0/N56436) (RLOC=X5Y10, Set=uChip0_Cal1_XA1_TA0/hset) >> Shift symbol "uChip0_Cal1_XA1_TA0/BU1014" (Output Signal = >> uChip0_Cal1_XA1_TA0/N56799) (RLOC=X5Y10, Set=uChip0_Cal1_XA1_TA0/hset) >> FLOP symbol "uChip0_Cal1_XA1_TA0/BU1017" (Output Signal = >> uChip0_Cal1_XA1_TA0/N720) (RLOC=X5Y10, Set=uChip0_Cal1_XA1_TA0/hset) >> The component is already of type "SLICEM". The setting of the >> component type >> is necessary since it is an odd number of columns away from a component >> which >> already has a type of "SLICEM". This second component contains the >> following >> symbols: >> Shift symbol "uChip0_Cal1_XA1_TA0/BU996" (Output Signal = >> uChip0_Cal1_XA1_TA0/N56748) (RLOC=X4Y10, Set=uChip0_Cal1_XA1_TA0/hset) >> FLOP symbol "uChip0_Cal1_XA1_TA0/BU999" (Output Signal = >> uChip0_Cal1_XA1_TA0/N56731) (RLOC=X4Y10, Set=uChip0_Cal1_XA1_TA0/hset) >> Shift symbol "uChip0_Cal1_XA1_TA0/BU1001" (Output Signal = >> uChip0_Cal1_XA1_TA0/N56768) (RLOC=X4Y10, Set=uChip0_Cal1_XA1_TA0/hset) >> FLOP symbol "uChip0_Cal1_XA1_TA0/BU1004" (Output Signal = >> uChip0_Cal1_XA1_TA0/N56430) (RLOC=X4Y10, Set=uChip0_Cal1_XA1_TA0/hset) >> This architecture has two types of components, SLICELs and SLICEMs, in >> alternating columns. Only SLICEMs can contain RAM symbols. >> > >
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