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
I read with interest your thoughts about hdl vs schematics and the parallel with software I've developped software for 14 years and while at heart I agree with you, in my day to day practice I disagree. Assembler will always provide you a most optimized solution, but C/C++ is much faster to develop with and is more accessible; btw, that's assuming you have competent engineers writing assembler, otherwise it turns into a mess very quick. yes, you definetly lower the efficiency of the resource usage with a higher level language, but nowadays it is cheaper to get faster / bigger hardware than more engineers / time. the days where we used to build things right are over; now the key is how fast you can put something on the market; it's sad, but the tech industry is not what it used to be. I have never been too much in touch with the hardware industry, but lately it has changed and I realize that you guys have the exact same issues / concerns / problems / etc we have in software; kind of ironic, in a sad way. Thomas. On Wed, 25 Jun 2003 22:23:48 -0400, Patrick MacGregor <patrickmacgregor@comcast.net> wrote: > Amen brother! > > The "pay" tools are essentially the same, and work just as deplorably. I > have a copy of ISE 5.2, and it uses the same sorry excuse for a schematic > editor. I invented the "hexplitive", which was swearing in base 16, when > working with X schematic tools. > > Xilinx clearly has no interest in catering to the schematic entry crowd > and > their tools show it. Their schematic tools are about as good as > something > like OrCad was -- OrCad from 15 years ago running under DOS that is. > > I have worked exclusively with Altera tools since the late '80s because > their support for schematics was SO MUCH better. There is simply no > comparison. I think that for most FPGA designs, X or A parts would work > just fine. However, the crap you have to go through to use X tools was > never worth it. Still isn't in my book. Their tools can take a one day > design and turn it into a week of rebooting and hair pulling. > > I also can't buy into the HDL argument. The reason is simple. If you > were > a software developer and you needed your code to be as small as possible > and > run as fast as possible, what language would you use? Well, every > software > developer I've ever met answers the same -- native assembly language for > the > processor in question. No compiled code will be more efficient because > of > the layers of abstraction that higher level languages impose. The > embedded > developers I've worked with always got a good chuckle out of their C > language counterparts sucking up 100's of kilobytes of memory compared to > the few K that their assembly code needed. > > HDL is the same. You abstract designs (so that non-designers can pretend > to > be designers I suppose) and pay a penalty by having circuit bloat. If > you > want the smallest design possible, and want it to run as fast as > possible, > you need to use the design equivalent of assembly coding -- i.e. > schematics. > A picture is worth a thousand words, so you can make a picture or type a > thousand words. Which one will be easier for someone else to understand, > hmm? > > I recently talked to an FAE for an FPGA vendor. He said that fully 80% > of > the designs he has seen are done in schematics. You can even read about > graphical versions of HDL coming out. Sounds like schematics to me. > Except > that you add a layer of obfuscation in there that will make for a more > bloated design. Why bother? > > An ironic thing to notice is that if you open many of the X design > examples > included with the tools, you'll see that they are schematic based. > > With a schematic it is sooooo simple to identify each and every flop and > see > what it is doing in a simulation. Something isn't working in HDL? Good > luck. Oh yeah, and with schematics, you never have to do all that > modeling > nonsense. While most "designers" are modeling what their circuit is > supposed to do, I've already got it done, simulated, verified on the > bench, > off my plate and onto the next thing. > > I was taught the power of schematics and their companion, the timing > diagram, when I was a wee engineer pup. My first boss would sit me down > and > go over the schematics with me, asking me to justify each and every > component on the page. If there wasn't a good reason for it, it was > gone. > Amongst the many invaluable lessons he taught me was that every component > in > the circuit should have a reason. Try doing that with an HDL > abstraction. > Most "designers" haven't a clue how that hunk of code they wrote got > implemented in actual gates. Scott Adams would probably call them > "Duhsigners". > > <getting off soapbox now> > > So, I'm with you 100%. Schematics rule. Xilinx has no reason whatsoever > to > support schematics, as the bloated designs that HDLs produce force folks > into buying larger, faster speed grade parts that are naturally more > costly. Works for them. > > You can always download the free Altera tools and play with their stuff. > Fully integrated schematic capture, compiler and simulator. Very nice. > Not > perfect or bug free, but then no tool is. It is, however, VASTLY > superior > to the X garbage schematic tools. > > When I need to design something in an X part, I do it first in the A > tools > and use their native simulater. Then I re-enter it in X. Doing the > drawings twice is STILL faster than doing the design from scratch in X. > Try > it. > > I tend to always push my clients to use A parts simply because the tools > are > so superior. Design times are radically reduced, and that saves them > tangible money. If they insist on X parts, I revert to the paragraph > above. > > Don't buy into the HDL propaganda. Schematics will never do you wrong. > > > > > > > "Chris Carlen" <crcarle@BOGUS.sandia.gov> wrote in message > news:bdcqge$jo5$1@sass2141.sandia.gov... >> Hi: >> >> Here's a chronicle of today's headaches. >> >> 1. ECS schematic editor can't deal with filenames that contain anything >> except 0-9 a-z A-Z . >> >> 2. I selected a large block of schematic, and when I tried to move it, >> ECS said "Internal Error: Delete Branch" >> >> 3. I guess nobody uses schematic entry because the editor is simply >> impossible to use. It is an absolute disaster. I try to select a group >> of objects to move, and it simply won't let me select them. They don't >> highlight. I try to select everything I have drawn to move it, and I >> get error mentioned in #2 above. The autorouting is useless. Get rid >> of it. Hint: humans are smarter than computers. Just let me draw my >> own wires. >> >> 4. Oh good grief, I moved some things, and then I simply cannot select >> anything anymore. >> >> You see folks, when you make software this bad, even if it is free, >> rather than making me want to pay for the "good" software, it makes me >> think you simply can't write good software. What evidence do I have >> that if I pay for your non-free tools, that they will be any better? >> None. On the contrary, I have volumous evidence that I will simply be >> paying for the exact same thing, only I will not only be frustrated, but >> poorer. The end result is the same. I can't use your silicon. >> >> So perhaps I have made a big mistake. Perhaps I should have gone with >> Altera. I just don't know now. >> >> Or perhaps analog design would be a way to avoid all this crap >> altogether. I don't seem to have much trouble with SPICE simulators. >> Heck even Linear Technology's LTSpice *FREE* simulator is very useable. >> >> Argh! >> >> >> 5. I closed the schematic editor hoping that if I re-opened my file it >> might reset som eof its internal data structures, and start working >> again. Now I try to reopen my schematic source from Project Navigator, >> and nothing happens. It simply sits there when I click "open". >> >> <Mr. Carlen strikes head with palm, to try to wake up from the bad >> dream.> >> >> Nope this is reality. Bummer. >> >> Aha! Project Navigator couldn't open my source because it didn't have >> the same name that I created it with. I created it as "cross32-52" >> which Project Navigator accepted just fine. But ECS wouldn't save the >> file with this name, even though it opened it the first time. So I >> saved it as something else, which of course broke Project Navigator. >> Well that's certainly my fault. I should have expected ECS to not save >> filenames with '-' characters. >> >> 6. After closing everything an reopening, I can select and move things >> in ECS again. Oh joy! >> >> 7. I wanted to start a new project to develop a modified version of a >> previous design done from scratch in 5.2i. I copied the .sch and .ucf >> files to the new project dir. I can edit the schematic, so I deleted >> some stuff I didn't want in there. Then I can't open the .ucf file >> because it has nets that aren't in the schematic. I don't know why in >> the original project, when I would add or remove nets from the >> schematic, the user constraints file was automatically updated to >> reflect the nets in the schematic. This doesn't work now, but perhaps >> it's because there is some file missing. >> >> So I will remove the .ucf source and add a new one which I'll set up >> from scratch. I click "remove" and then I add a new source, a user >> constraints with the same name as the one that isn't working. Project >> NAvigator prompts me if I want to overwrite the old file. I click "Ok" >> and expect that when I open the new .ucf file, it will be a reflection >> of the nets in my schematic. >> >> No such luck, the broken .ucf was not everwritten, so it still complains >> of errors of missing nets. >> >> >> Well that's all before lunch time. Let's see what happens this > afternoon... >> >> >> I guess if there's a point to all this, I should look around on Xilinx's >> web site some more and find out where to report bugs. But I have >> reached a point with software in general where I am tired of doing this. >> That is because, I often wind up spending hours reporting the bugs in >> the rigorous detail that is needed if there is to be any hope of anyone >> actually fixing them. Unless of course, the software had been >> rigorously tested in the first place. >> >> >> >> -- >> _______________________________________________________________________ >> Christopher R. Carlen >> Principal Laser/Optical Technologist >> Sandia National Laboratories CA USA >> crcarle@sandia.gov -- NOTE: Remove "BOGUS" from email address to reply. >> > > >Article: 57226
I'm quite sure that the physical cable connection is ok actually, the platform I use is ML300 and I try to program the xc2vp7 via the Parallel Cable IV. Does anyone have the experience on it ? Are there any settings on the ML300 board I should pay attention to ? Thanks in advance. tk "Neil Glenn Jacobson" <neil.jacobson@xilinx.com> wrote in message news:3EF9F98F.30402@xilinx.com... > iMPACT is telling you that you are getting all 0's back from the device > when it is expecting the IDCODE. Assuming the device is currently > unprogrammed, I would first check your physical cable connections to the > device making certain that the device itself and the cable are both > properly powered > > This error does not appear to be related to the software > > tk wrote: > > Hi all, > > > > I get the following error when I try to program xc2vp7 device using iMPACT > > (ISE 5.1i): > > > > ERROR:iMPACT:583 - '1': The idcode read from the device does not match the > > idcode in the bsdl File. > > INFO:iMPACT:629 - '1': Device IDCODE : 00000000000000000000000000000000 > > INFO:iMPACT:630 - '1': Expected IDCODE: 00000001001001001010000010010011 > > > > I've found that this problem is discussed in the Xilinx web page: > > http://support.xilinx.com/xlnx/xil_ans_display.jsp?iLanguageID=1&iCountryID= > > 1&getPagePath=16490 > > > > However, I don't use the encryption function for the bitstream. Why I still > > get the problem? > > Even I install the service pack 3, the problem is still there. > > Can anyone kindly tell me how to solve it? > > Thanks in advance. > > > > tk > > > > > > PS: the following are the options used by BitGen: > > > > Summary of Bitgen Options: > > +----------------------+----------------------+ > > | Option Name | Current Setting | > > +----------------------+----------------------+ > > | Compress | (Not Specified)* | > > +----------------------+----------------------+ > > | Readback | (Not Specified)* | > > +----------------------+----------------------+ > > | CRC | Enable** | > > +----------------------+----------------------+ > > | DebugBitstream | No** | > > +----------------------+----------------------+ > > | ConfigRate | 4** | > > +----------------------+----------------------+ > > | StartupClk | JtagClk | > > +----------------------+----------------------+ > > | DCMShutdown | Disable** | > > +----------------------+----------------------+ > > | DisableBandgap | No** | > > +----------------------+----------------------+ > > | CclkPin | Pullup** | > > +----------------------+----------------------+ > > | DonePin | Pullup** | > > +----------------------+----------------------+ > > | HswapenPin | Pullup* | > > +----------------------+----------------------+ > > | M0Pin | Pullup** | > > +----------------------+----------------------+ > > | M1Pin | Pullup** | > > +----------------------+----------------------+ > > | M2Pin | Pullup** | > > +----------------------+----------------------+ > > | PowerdownPin | Pullup** | > > +----------------------+----------------------+ > > | ProgPin | Pullup** | > > +----------------------+----------------------+ > > | TckPin | Pullup** | > > +----------------------+----------------------+ > > | TdiPin | Pullup** | > > +----------------------+----------------------+ > > | TdoPin | Pullnone | > > +----------------------+----------------------+ > > | TmsPin | Pullup** | > > +----------------------+----------------------+ > > | UnusedPin | Pulldown** | > > +----------------------+----------------------+ > > | GWE_cycle | 6** | > > +----------------------+----------------------+ > > | GTS_cycle | 5** | > > +----------------------+----------------------+ > > | LCK_cycle | NoWait** | > > +----------------------+----------------------+ > > | Match_cycle | NoWait | > > +----------------------+----------------------+ > > | DONE_cycle | 4** | > > +----------------------+----------------------+ > > | Persist | No* | > > +----------------------+----------------------+ > > | DriveDone | No** | > > +----------------------+----------------------+ > > | DonePipe | No** | > > +----------------------+----------------------+ > > | Security | None** | > > +----------------------+----------------------+ > > | UserID | 0xFFFFFFFF** | > > +----------------------+----------------------+ > > | ActivateGclk | No* | > > +----------------------+----------------------+ > > | ActiveReconfig | No* | > > +----------------------+----------------------+ > > | PartialMask0 | (Not Specified)* | > > +----------------------+----------------------+ > > | PartialMask1 | (Not Specified)* | > > +----------------------+----------------------+ > > | PartialMask2 | (Not Specified)* | > > +----------------------+----------------------+ > > | PartialGclk | (Not Specified)* | > > +----------------------+----------------------+ > > | PartialLeft | (Not Specified)* | > > +----------------------+----------------------+ > > | PartialRight | (Not Specified)* | > > +----------------------+----------------------+ > > | Encrypt | No** | > > +----------------------+----------------------+ > > | Key0 | pick* | > > +----------------------+----------------------+ > > | Key1 | pick* | > > +----------------------+----------------------+ > > | Key2 | pick* | > > +----------------------+----------------------+ > > | Key3 | pick* | > > +----------------------+----------------------+ > > | Key4 | pick* | > > +----------------------+----------------------+ > > | Key5 | pick* | > > +----------------------+----------------------+ > > | Keyseq0 | M* | > > +----------------------+----------------------+ > > | Keyseq1 | M* | > > +----------------------+----------------------+ > > | Keyseq2 | M* | > > +----------------------+----------------------+ > > | Keyseq3 | M* | > > +----------------------+----------------------+ > > | Keyseq4 | M* | > > +----------------------+----------------------+ > > | Keyseq5 | M* | > > +----------------------+----------------------+ > > | KeyFile | (Not Specified)* | > > +----------------------+----------------------+ > > | StartKey | 0* | > > +----------------------+----------------------+ > > | StartCBC | pick* | > > +----------------------+----------------------+ > > | IEEE1532 | No* | > > +----------------------+----------------------+ > > | Binary | No** | > > +----------------------+----------------------+ > > * Default setting. > > ** The specified setting matches the default setting. > > > > >Article: 57227
Hi - The this-tool-is-no-damn-good thread pops up every few weeks. I don't use the ECS schematic editor, so I can't comment on the its quality or lack thereof. And I certainly don't want to get embroiled in the schematics-vs-HDL debate which, along with cockroaches, will be the only thing to survive a nuclear holocaust. But I will make a couple of observations. First, use tools that have lots of users. Any tool developer will spend more time fixing and maintaining popular tools than those used only by a handful of people. And, the merits of HDLs aside, is there any doubt that even the least popular FPGA HDL synthesis tool has at least ten times as many users as ECS? I know, I know--this isn't fair. But that's the way it is. Unless you're Mr. Cisco, of course. Second, use only those tools that add real value. There are some Xilinx tools--the FPGA editor, PACE, the floorplanner--that have a useful GUI . In fact, these tools wouldn't make much sense without a GUI. But does Project Navigator really add that much value over and above a decent batch file that invokes tools from the command line? Maybe the uber-GUI that ties all the tools together makes sense for some users, but to me it's just one more thing that can break or do inexplicable things. All I'm saying is, don't use a tool just because it's there; the benefit should exceed the pain. And I agree - the Linear Tech SPICE tool is very nice. The fact that it's free doesn't hurt, either. Bob Perlman Cambrian Design WorksArticle: 57228
Hi all, I have problem in configuring the xc2vp7 on the ML300 board. The problem is described in the previous thread "ERROR:iMPACT:583". I doubt that I have omitted some settings on the ML300 board during programming (or have done sth wrong in iMPACT). There is a button called "FPGA PROG" on the ML300 board. I've searched through the documentation but I couldn't find out what's it for. Does anyone have the experience on using ML300 that can share with me ? Thanks very much. tkArticle: 57229
always @ (posedge(clkin))
clkout <= ~clkout;
above is a single clk_div module, but when I do simulation, I can't get it
work.
I know the reason. without a reset signal to give it a initial value of '0'
or '1', the clkout will keep the value 'x' during simulation.
but there's no 'x' in FPGA or CPLD, the clkout will get whatever a value
after power up, and it can get work without additional reset.
just a example, but in my design I really have some modules that haven't a
reset.
How can I simulate this modules? in testbench I tried to initiate the
clkout, but failed.
(ISE5.1 + ModelSim)
Article: 57230Patrick MacGregor wrote: > > Amen brother! > > The "pay" tools are essentially the same, and work just as deplorably. I > have a copy of ISE 5.2, and it uses the same sorry excuse for a schematic > editor. I invented the "hexplitive", which was swearing in base 16, when > working with X schematic tools. > ...snip... > I also can't buy into the HDL argument. The reason is simple. If you were > a software developer and you needed your code to be as small as possible and > run as fast as possible, what language would you use? Well, every software > developer I've ever met answers the same -- native assembly language for the > processor in question. No compiled code will be more efficient because of > the layers of abstraction that higher level languages impose. The embedded > developers I've worked with always got a good chuckle out of their C > language counterparts sucking up 100's of kilobytes of memory compared to > the few K that their assembly code needed. But you ignore the fact that very few embedded engineers need their code to be "as small as possible" or "fast as possible". That is because the hardware gives lots of head room for very few bucks. Likewise FPGAs generally are more than fast enough and large enough and cheap enough (did *I* say that?) for 95% of the designs to be done in HDL. Again for the same reason that few designers do an entire project in assembly, I won't be doing any more schematic designs. The last one I did was a PITA to draw the gates needed for FSM design or worse, address decoding. Data path is not bad in schematic, but the random logic is no fun at all and it takes up so much space when you try to view a large design. I don't mean disk space, I mean viewing space. I can view an equivalent project in a text editor much more easily than a schematic editor. > HDL is the same. You abstract designs (so that non-designers can pretend to > be designers I suppose) and pay a penalty by having circuit bloat. If you > want the smallest design possible, and want it to run as fast as possible, > you need to use the design equivalent of assembly coding -- i.e. schematics. > A picture is worth a thousand words, so you can make a picture or type a > thousand words. Which one will be easier for someone else to understand, > hmm? There are lots of reasons to use HDLs, but trying to enable uneducated hardware designers (or worse, software designers) is not one of them. I feel that to properly use an HDL you need to know what you expect for hardware and then describe that in the HDL. But again, very few people have to have the "smallest" or the "fastest" design. Mostly they have goals which include schedules. As to the picture and word analogy, I find the words to suit design better. It takes a large picture and a lot of time to create it, to equal those thousand words. > I recently talked to an FAE for an FPGA vendor. He said that fully 80% of > the designs he has seen are done in schematics. You can even read about > graphical versions of HDL coming out. Sounds like schematics to me. Except > that you add a layer of obfuscation in there that will make for a more > bloated design. Why bother? I don't know where you got this, but this sounds like an exaggeration. I would say he had it backwards, but I bet the schematic usage is less than 20%. > An ironic thing to notice is that if you open many of the X design examples > included with the tools, you'll see that they are schematic based. > > With a schematic it is sooooo simple to identify each and every flop and see > what it is doing in a simulation. Something isn't working in HDL? Good > luck. Oh yeah, and with schematics, you never have to do all that modeling > nonsense. While most "designers" are modeling what their circuit is > supposed to do, I've already got it done, simulated, verified on the bench, > off my plate and onto the next thing. If you don't feel the need to simulate, then you are clearly doing very simple designs. The simulation is to make sure you are solving the problem rather than just knowing what you are creating. These are two different problems. > I was taught the power of schematics and their companion, the timing > diagram, when I was a wee engineer pup. My first boss would sit me down and > go over the schematics with me, asking me to justify each and every > component on the page. If there wasn't a good reason for it, it was gone. > Amongst the many invaluable lessons he taught me was that every component in > the circuit should have a reason. Try doing that with an HDL abstraction. > Most "designers" haven't a clue how that hunk of code they wrote got > implemented in actual gates. Scott Adams would probably call them > "Duhsigners". > > <getting off soapbox now> > > So, I'm with you 100%. Schematics rule. Xilinx has no reason whatsoever to > support schematics, as the bloated designs that HDLs produce force folks > into buying larger, faster speed grade parts that are naturally more > costly. Works for them. > > You can always download the free Altera tools and play with their stuff. > Fully integrated schematic capture, compiler and simulator. Very nice. Not > perfect or bug free, but then no tool is. It is, however, VASTLY superior > to the X garbage schematic tools. > > When I need to design something in an X part, I do it first in the A tools > and use their native simulater. Then I re-enter it in X. Doing the > drawings twice is STILL faster than doing the design from scratch in X. Try > it. > > I tend to always push my clients to use A parts simply because the tools are > so superior. Design times are radically reduced, and that saves them > tangible money. If they insist on X parts, I revert to the paragraph above. > > Don't buy into the HDL propaganda. Schematics will never do you wrong. No, but they will take more time and make large jobs nearly impossible. -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAXArticle: 57231
hi,
I am working on a HANDELC project on Xilinx FPGA(RC1000 board) and using Celoxica's DK1 environment. I have some doubts regarding HANDELC. I am new to HANDELC and FPGA.
The Problem
-----------
As the project is getting bigger and bigger, the compilation(synthesis into EDIF) time is taking many hours. So the goal is to reduce the compilation time.
The approach which I tried to use was to break up the program into smaller parts, compile these into separate EDIFs and hook them into the main HANDELC program using interfaces(ports). So the parts of the program which have already been synthesized into EDIF do not take any time at all thus saving lot of time.
But I am doing some mistake in my code and I am clueless to what is wrong. Actually I feel that I need to synchronise the EDIF component with the main HANDELC program but don't know how ( maybe use interfaces properly???). I have given below the detailed description of the things I tried.
Here is the code for the main HANDELC program:(compiles to test.edf)
---------------------------------------------
#define PP1000_32BIT_RAMS
#define PP1000_DIVIDE4
#define PP1000_CLOCK PP1000_MCLK
#include "C:\rc1000pp\fpga\virtex\pp1000.h"
set part = "V1000BG560-4";
set family = XilinxVirtex;
unsigned 8 value;
/* here interface to the component is defined */
interface test2
(unsigned 8 ret_val)
test2_instance
(unsigned int 8 x = value);
void main (void)
{
/****
Interaction with the board is done .
just reading some data from Memory banks which is written
by a VC++ host program using RC1000 board API.
Actually this data needs to be processed.
To simplify the issue it's not given here.
This is gauranteed to be correct, I tested it.
****/
value = 10; /* input to component EDIF */
/* trying to use the EDIF component */
while(test2_instance.ret_val == 0){delay;};
value = test2_instance.ret_val;
/****
Interaction with board.
just writing some processed data into memory bank.
This part is gauranteed to be correct, I tested it. */
****/
}
HANDELC code for the EDIF component (it compiles to test2.edf)
-----------------------------------
unsigned 8 value1;
interface port_in
(unsigned int 8 x)
comp_inp
();
interface port_out
()
comp_outp
(unsigned 8 ret_val = value1);
set clock = external; /* I am clueless here what clock to use */
void main(void)
{
value1 = comp_inp.x * 10;
}
First I compile the above code to get test2.edf and then use the Xilinx place and route tool to merge both the edifs to get test.bit file.
But the above program does not work at all. Always I get value 0 when i read from the memory bank but the value is supposed to be 100. Also another suspicious thing is that the check for (ret_val==0) in the main HANDELC code surprisingly takes a long time (around 8 secs).
One more observation is that even if I explicitly write a value after the two statements as given below:
/* trying to use the EDIF component */
while(test2_instance.ret_val == 0){delay;};
value = test2_instance.ret_val;
value = 100; /* introduced now just to debug*/
/****
Interaction with board.
just writing some processed data into memory bank.
****/
still it gives 0. But if I remove the two statements trying to access the component, without removing the newly introduced statement,then the read value is 100 as required .
Plzzzzz help.
regards,
P.Prasad
Article: 57232"Patrick MacGregor" <patrickmacgregor@comcast.net> writes: <snip> > I also can't buy into the HDL argument. The reason is simple. If you were > a software developer and you needed your code to be as small as possible and > run as fast as possible, what language would you use? Well, every software > developer I've ever met answers the same -- native assembly language for the > processor in question. No compiled code will be more efficient because of > the layers of abstraction that higher level languages impose. The embedded > developers I've worked with always got a good chuckle out of their C > language counterparts sucking up 100's of kilobytes of memory compared to > the few K that their assembly code needed. > The point as already been made that very few people write the whole thing in assembly. > HDL is the same. You abstract designs (so that non-designers can pretend to > be designers I suppose) and pay a penalty by having circuit bloat. If you > want the smallest design possible, and want it to run as fast as possible, > you need to use the design equivalent of assembly coding -- i.e. schematics. > A picture is worth a thousand words, so you can make a picture or type a > thousand words. Which one will be easier for someone else to understand, > hmm? > HDL doesn't force abstration - you can write gate-level HDL. There are illustrious people populating this group who frequently do the "design equivalent of assembly coding" in HDL. Come to think of it, last time I did a schematic I used the "abstraction" of a counter block, which hides flops inside it. Only if you know how to make a counter do you know "where every flop is". And that's the same in HDL - I know I've written code that will mean a counter gets built, so I know what flops there are there. <snip> > > With a schematic it is sooooo simple to identify each and every flop and see > what it is doing in a simulation. Something isn't working in HDL? Good > luck. Oh yeah, and with schematics, you never have to do all that modeling > nonsense. While most "designers" are modeling what their circuit is > supposed to do, I've already got it done, simulated, verified on the bench, > off my plate and onto the next thing. > What do you do when your two BGA packages aren;t talking to each other and you haven't got the chance (because of signal integrity concerns) to put a probe point on the board? I go back to my simulation, with its models and all that 'waste of time'. Another advantage of this approach is that I can write a testbench that covers all my (many) testcases and reports a pass or fail at the end. That way I can modify any code I like and know I haven't recreated any old bugs. Not quite so easy when staring at waveforms... <snip> Just some thoughts from the other side! Cheers, Martin -- martin.j.thompson@trw.com TRW Conekt, Solihull, UK http://www.trw.com/conektArticle: 57234
Hi, i'm currently looking at Xapp151 which describes the rough format of the bitstream for Virtex, Virtex-E and Virtex-EM. However I have a Virtex 2 Pro (V2P20). Is there any similiar document for that architecture? And if not, is there someone who has tested this and can give my some tips about differences? TIA Felix -- /"\ ASCII ribbon campaign against HTML mail and postings. \ / X "Ich will eigentlich keinen Streit - ich will nur Recht haben" / \ Thorsten Gunkel am 15.01.2000Article: 57235
the problem is solved! There are two options in iMPACT in bounday-scan chain: 1. Automatically connect to cable and identify Boundary-Scan chain 2. Enter a Boundary-Scan Chain If I choose 2, only the xc2vp7 is chosen, which causes the error. If I choose 1, there are 2 devices detected in the bounday-scan chain, namely xccace and xc2vp7. The xc2vp7 can be successfully programmed in this case by assigning the correct .bit file. "tk" <tokwok@hotmail.com> ¼¶¼g©ó¶l¥ó news:bde17q$igm$1@www.csis.hku.hk... > I'm quite sure that the physical cable connection is ok > > actually, the platform I use is ML300 and I try to program the xc2vp7 via > the > Parallel Cable IV. Does anyone have the experience on it ? Are there any > settings on the ML300 board I should pay attention to ? > > Thanks in advance. > > tk > > "Neil Glenn Jacobson" <neil.jacobson@xilinx.com> wrote in message > news:3EF9F98F.30402@xilinx.com... > > iMPACT is telling you that you are getting all 0's back from the device > > when it is expecting the IDCODE. Assuming the device is currently > > unprogrammed, I would first check your physical cable connections to the > > device making certain that the device itself and the cable are both > > properly powered > > > > This error does not appear to be related to the software > > > > tk wrote: > > > Hi all, > > > > > > I get the following error when I try to program xc2vp7 device using > iMPACT > > > (ISE 5.1i): > > > > > > ERROR:iMPACT:583 - '1': The idcode read from the device does not match > the > > > idcode in the bsdl File. > > > INFO:iMPACT:629 - '1': Device IDCODE : 00000000000000000000000000000000 > > > INFO:iMPACT:630 - '1': Expected IDCODE: 00000001001001001010000010010011 > > > > > > I've found that this problem is discussed in the Xilinx web page: > > > > http://support.xilinx.com/xlnx/xil_ans_display.jsp?iLanguageID=1&iCountryID= > > > 1&getPagePath=16490 > > > > > > However, I don't use the encryption function for the bitstream. Why I > still > > > get the problem? > > > Even I install the service pack 3, the problem is still there. > > > Can anyone kindly tell me how to solve it? > > > Thanks in advance. > > > > > > tk > > > > > > > > > PS: the following are the options used by BitGen: > > > > > > Summary of Bitgen Options: > > > +----------------------+----------------------+ > > > | Option Name | Current Setting | > > > +----------------------+----------------------+ > > > | Compress | (Not Specified)* | > > > +----------------------+----------------------+ > > > | Readback | (Not Specified)* | > > > +----------------------+----------------------+ > > > | CRC | Enable** | > > > +----------------------+----------------------+ > > > | DebugBitstream | No** | > > > +----------------------+----------------------+ > > > | ConfigRate | 4** | > > > +----------------------+----------------------+ > > > | StartupClk | JtagClk | > > > +----------------------+----------------------+ > > > | DCMShutdown | Disable** | > > > +----------------------+----------------------+ > > > | DisableBandgap | No** | > > > +----------------------+----------------------+ > > > | CclkPin | Pullup** | > > > +----------------------+----------------------+ > > > | DonePin | Pullup** | > > > +----------------------+----------------------+ > > > | HswapenPin | Pullup* | > > > +----------------------+----------------------+ > > > | M0Pin | Pullup** | > > > +----------------------+----------------------+ > > > | M1Pin | Pullup** | > > > +----------------------+----------------------+ > > > | M2Pin | Pullup** | > > > +----------------------+----------------------+ > > > | PowerdownPin | Pullup** | > > > +----------------------+----------------------+ > > > | ProgPin | Pullup** | > > > +----------------------+----------------------+ > > > | TckPin | Pullup** | > > > +----------------------+----------------------+ > > > | TdiPin | Pullup** | > > > +----------------------+----------------------+ > > > | TdoPin | Pullnone | > > > +----------------------+----------------------+ > > > | TmsPin | Pullup** | > > > +----------------------+----------------------+ > > > | UnusedPin | Pulldown** | > > > +----------------------+----------------------+ > > > | GWE_cycle | 6** | > > > +----------------------+----------------------+ > > > | GTS_cycle | 5** | > > > +----------------------+----------------------+ > > > | LCK_cycle | NoWait** | > > > +----------------------+----------------------+ > > > | Match_cycle | NoWait | > > > +----------------------+----------------------+ > > > | DONE_cycle | 4** | > > > +----------------------+----------------------+ > > > | Persist | No* | > > > +----------------------+----------------------+ > > > | DriveDone | No** | > > > +----------------------+----------------------+ > > > | DonePipe | No** | > > > +----------------------+----------------------+ > > > | Security | None** | > > > +----------------------+----------------------+ > > > | UserID | 0xFFFFFFFF** | > > > +----------------------+----------------------+ > > > | ActivateGclk | No* | > > > +----------------------+----------------------+ > > > | ActiveReconfig | No* | > > > +----------------------+----------------------+ > > > | PartialMask0 | (Not Specified)* | > > > +----------------------+----------------------+ > > > | PartialMask1 | (Not Specified)* | > > > +----------------------+----------------------+ > > > | PartialMask2 | (Not Specified)* | > > > +----------------------+----------------------+ > > > | PartialGclk | (Not Specified)* | > > > +----------------------+----------------------+ > > > | PartialLeft | (Not Specified)* | > > > +----------------------+----------------------+ > > > | PartialRight | (Not Specified)* | > > > +----------------------+----------------------+ > > > | Encrypt | No** | > > > +----------------------+----------------------+ > > > | Key0 | pick* | > > > +----------------------+----------------------+ > > > | Key1 | pick* | > > > +----------------------+----------------------+ > > > | Key2 | pick* | > > > +----------------------+----------------------+ > > > | Key3 | pick* | > > > +----------------------+----------------------+ > > > | Key4 | pick* | > > > +----------------------+----------------------+ > > > | Key5 | pick* | > > > +----------------------+----------------------+ > > > | Keyseq0 | M* | > > > +----------------------+----------------------+ > > > | Keyseq1 | M* | > > > +----------------------+----------------------+ > > > | Keyseq2 | M* | > > > +----------------------+----------------------+ > > > | Keyseq3 | M* | > > > +----------------------+----------------------+ > > > | Keyseq4 | M* | > > > +----------------------+----------------------+ > > > | Keyseq5 | M* | > > > +----------------------+----------------------+ > > > | KeyFile | (Not Specified)* | > > > +----------------------+----------------------+ > > > | StartKey | 0* | > > > +----------------------+----------------------+ > > > | StartCBC | pick* | > > > +----------------------+----------------------+ > > > | IEEE1532 | No* | > > > +----------------------+----------------------+ > > > | Binary | No** | > > > +----------------------+----------------------+ > > > * Default setting. > > > ** The specified setting matches the default setting. > > > > > > > > > >Article: 57236
Hi, Has anyone executed partial reconfiguration of RC1000 using the RC1000-PP host support library provided by Celoxica(previously Embedded Solutions Ltd)? Would like what are the steps to achieve this? Thanks.Article: 57237
> What if I were to modify the data out such that its similar to NTSC and then > pass it the encoder core. > > Instead of VGA, I could output 1 field at a time 30 Hz > (still at 640x480). That sounds plausible.Article: 57238
Hi Jay, i'm using vhdl, but should work in verilog, too: declaring 'clkout', use an initial value! signal clkout: std_logic := '0'; perhaps, you will have to ignore a synthesis-warning...Article: 57239
Hi all! I have a problem while trying to reuse a IP generated with the Coregen Tool. I used the CoreGen (ISE 5.1) to generate my IP (everything seems ok) and after I have reused that IP in another design using Synplify Pro (like a black box, every thing ok, till here) and while trying to synthesize in ISE I've got the error: Ngdbuild:604: logical block 'XXX' with type 'YYY' could not be resolved. A pin name misspelling can cause this, a missing edif or ngc file, or the misspelling of a type name. Symbol 'YYY' is not supported in target 'virtex2'. I have no idea of what's going on. The IP core seems correct and the edf/ngo files for the IP are present in the propper direcotry at $Xilinx/coregen/ Some has had the same problem before? Maybe a problem with the spelling of the ports (upper/lower case)? Thanks, SantiArticle: 57240
Robert Myers wrote: > Possible solutions: get away from Manhattan > routing (25% savings in wire delay--yawn) He even said this was "novel". Looking at the 25 years old die of the 8086, 45 angle wiring wasn't novel back then - when layout was made by hand, and digitized afterwards. What's novel is chip place&route tools that can handle 45 angle wiring. Repeater/buffer insertion: nothing new, and trivial to do automatically. -- Bernd Paysan "If you want it done right, you have to do it yourself" http://www.jwdt.com/~paysan/Article: 57241
"Patrick MacGregor" <patrickmacgregor@comcast.net> wrote in message news:<TYmcncAzX4PaxGejXTWJhw@comcast.com>... [snip] > HDL is the same. You abstract designs (so that non-designers can pretend to > be designers I suppose) and pay a penalty by having circuit bloat. If you > want the smallest design possible, and want it to run as fast as possible, > you need to use the design equivalent of assembly coding -- i.e. schematics. [snip] > Don't buy into the HDL propaganda. Schematics will never do you wrong. I believe your assumptions and comparisons of HDL are incorrect. HDL is not a normal programming language, and as such, can't be compared to something like C. And it does not cause circuit bloat. Incorrectly coded HDL can, but that's not the fault of the HDL - just like inefficient assembly code (yes, there is such a thing) is not the fault of the assembler. And I'm am certainly not anti-schematic - I've done two decent sized designs recently in Renoir. But the sole reason I do them in schematic form is to help myself and any others get a graphical picture of what is going on because they are somewhat complex designs. It has NOTHING to do with the coding or implementation efficiency - because it is not more efficient - at best, it is on par. And as Rick pointed out, on large designs it is difficult to "see" what is going on because when you zoom out, you can't see details, and when you zoom in, you lose some of the big picture. Lastly, FPGA's don't have many of the things you put in schematics. Do you use ONLY 4 input LUTs and D-FF's on your schematics? If you use much more than that, you are using a form of abstraction as well. Have fun, MarcArticle: 57242
> > I also can't buy into the HDL argument. The reason is simple. If you were > a software developer and you needed your code to be as small as possible and > run as fast as possible, what language would you use? Well, every software > developer I've ever met answers the same -- native assembly language for the > processor in question. No compiled code will be more efficient because of > the layers of abstraction that higher level languages impose. The embedded > developers I've worked with always got a good chuckle out of their C > language counterparts sucking up 100's of kilobytes of memory compared to > the few K that their assembly code needed. > > HDL is the same. You abstract designs (so that non-designers can pretend to > be designers I suppose) and pay a penalty by having circuit bloat. If you > want the smallest design possible, and want it to run as fast as possible, > you need to use the design equivalent of assembly coding -- i.e. schematics. > A picture is worth a thousand words, so you can make a picture or type a > thousand words. Which one will be easier for someone else to understand, > hmm? > I am an embedded systems programmer, and do a little bit of PLD design. I can't comment on X's schematic software - I have never used it, and I never will. I am expecting to work on a Xilinx fpga design soon, and I will use either VHDL or Verilog. Everyone is entitled to their own opinions, I suppose, but your comments on C and assembly programming just do not match reality. There are plenty of cases where assembly is the appropriate language - I program with small micros, which are wholy unsuited to high-level language. I also program in C on micros that are more suited for C, and I am well-versed in the sort of assembly code the C compilers generate. The reality is that for small, limited micros, assembly can be significantly faster and more compact - say half the size and double the speed for a good assembly programmer as compared to a good embedded C programmer (i.e., one that knows how to get the best out of a small micro), and maybe the same again compared to a good general C programmer. For big micros, especially 32-bitters, a good C programmer and a good C compiler will beat a good assembly programmer every time - bar a few, specialised routines where it is worth highly optomising assembly code. The idea of a compiler producing 100 K of bloat for 1K of program is laughable (or a very badly configured linker...). Now, I know that theoretically an assembly programmer could beat the compiler - after all, there is nothing that the compiler can do that the assembler programmer cannot do. But writing optimal assembly for big micros is a long, hard job, and programmers must balance writing optimal code with writing correct, maintainable, flexible and readible code. As a quick example, if the program requires a divide by a constant, the C compiler may optimise this to multiplying by its reciprical, and (assuming the micro does not have hardware multiplication), it might produce a series of in-line shifts and adds. If the assembler programmer expects that this constant might change, he would write a general divide routine - it is bigger and slower than the compiler-generated code, but far more understandable and more flexible for the future. FPGA design is the same. Some things can be better expressed as schematics, especially for small designs, and some designers will work better with schematics than HDL depending on their background, experiance, and interests. But to suggest that schematics are always easier to understand, or to design, or will always generate faster/smaller circuits, is just silly. And as for a picture being worth a thousand words, please draw me a picture that gives the equivilent information to the sentence "I'm taking my family on holiday to Finland in a couple of weeks, where we will be visiting Mumminland, Helsinki zoo, and a number of other attractions". I'm sure you could draw such a picture, and it would look very nice, but it would take far longer to draw and be much less accurate than the sentence.Article: 57243
Marc Randolph wrote: <Good stuff snipped> > Lastly, FPGA's don't have many of the things you put in schematics. > Do you use ONLY 4 input LUTs and D-FF's on your schematics? If you > use much more than that, you are using a form of abstraction as well. A larger abstraction used in schematics is the "wire" connecting between FF's and LUT's. This "wire" is an abstraction for a significant number of switch boxes, muxes and pips. FPGAs are more interconnect logic than user logic. -- Phil HaysArticle: 57244
Hi, What's your suggestion for a low-power, battery operated FPGA design? What family do you suggest? I guess the design should need something like 20K~30K gates (yeah, I know this does not all that correct but I've not syntesized the design yet and can't give a good estimate on number of LEs or FFs...). From what I've seen in data-sheets, besides the power consumption, one major concern is the power-up and configuration current for SRAM based devices. Also I'd like to have the minimum number of VCC voltages on the board and other parts used in the design are 3.3v and can be safely run using a single rechargable battery with no need for DC-DC converter circuit (it means that they can work from 2.7v to 4.1v with no problem). Best Regards ArashArticle: 57245
I have a design that I did almost 15 years ago that fits in a 20L10 PAL.
This was written in ABEL, a PALASM like language, that was created by
Data IO (now Synario).
I need to port this design to a 22V10, because these parts are more
readily available. This design is for a peripheral for one of the early
1980s home computers. After I port the design, I'm going to release it
into the public domain so enthusiasts of this machine can modify it if
they want. To facilitate this, I'd like to make sure that whatever tool
I use to synthesize the design can be had for free.
I'd prefer to use ABEL, because that would require the minimum amount of
design changes. Does anyone know if there are any old versions of ABEL
(by Data IO, now Synario) that have been released into the public
domain? If not, can anyone recall what form of copy protection, if any,
was used on the old DOS versions.
I know that Cypress has their Warp VHDL compiler for simple PALs,
including the 22V10. But, it still costs about $100. Are any of the
earlier versions available for free?
I guess I could always use PALASM. Anywone if the latest version of this
tool supports the 22V10? And where can I find it?
Or, are there other options I'm not aware of.
TIA
Paul
______________________________________________________________________
Posted Via Uncensored-News.Com - Still Only $9.95 - http://www.uncensored-news.com
<><><><><><><> The Worlds Uncensored News Source <><><><><><><><>
Article: 57246I would suggest using ACTEL. They have both otp devices and flash devices. These devices consume very little current 5mA standby. "Arash Salarian" <arash dot salarian at epfl dot ch> wrote in message news:3efaef99$1@epflnews.epfl.ch... > Hi, > > What's your suggestion for a low-power, battery operated FPGA design? What > family do you suggest? I guess the design should need something like 20K~30K > gates (yeah, I know this does not all that correct but I've not syntesized > the design yet and can't give a good estimate on number of LEs or FFs...). > From what I've seen in data-sheets, besides the power consumption, one major > concern is the power-up and configuration current for SRAM based devices. > Also I'd like to have the minimum number of VCC voltages on the board and > other parts used in the design are 3.3v and can be safely run using a single > rechargable battery with no need for DC-DC converter circuit (it means that > they can work from 2.7v to 4.1v with no problem). > > Best Regards > Arash > >Article: 57247
"Thomas" <tom3@protectedfromreality.com> wrote in message news:oprrcygwqomo2d8p@news3.news.adelphia.net... > I read with interest your thoughts about hdl vs schematics and the parallel > with software > I've developped software for 14 years and while at heart I agree with you, > in my day to day practice I disagree. Assembler will always provide you a > most optimized solution, but C/C++ is much faster to develop with and is > more accessible; btw, that's assuming you have competent engineers writing > assembler, otherwise it turns into a mess very quick. yes, you definetly > lower the efficiency of the resource usage with a higher level language, > but nowadays it is cheaper to get faster / bigger hardware than more > engineers / time. > the days where we used to build things right are over; now the key is how > fast you can put something on the market; it's sad, but the tech industry > is not what it used to be. > I have never been too much in touch with the hardware industry, but lately > it has changed and I realize that you guys have the exact same issues / > concerns / problems / etc we have in software; kind of ironic, in a sad > way. > > Thomas. The assembly level guys I've worked with were every bit as fast as their C counterparts when developing code. If you do it a lot, you get good, fast and efficient at it. And as with HW design, you create a bag of tricks you employ to speed the next jobs along, as well as developing a library of previously designed pieces you can employ later. There is just no reason why you can't design quickly and correctly at the same time. That is one key difference between a newbie and someone with a lot of experience. It is then incumbent on the experienced folks to pass along knowledge to the newbies to speed their development into capable, competent designers. Nothing beats experience.Article: 57248
"rickman" <spamgoeshere4@yahoo.com> wrote in message news:3EFA9377.E87AB5E7@yahoo.com... > Patrick MacGregor wrote: > > > > Amen brother! > > > > The "pay" tools are essentially the same, and work just as deplorably. I > > have a copy of ISE 5.2, and it uses the same sorry excuse for a schematic > > editor. I invented the "hexplitive", which was swearing in base 16, when > > working with X schematic tools. > > > ...snip... > > I also can't buy into the HDL argument. The reason is simple. If you were > > a software developer and you needed your code to be as small as possible and > > run as fast as possible, what language would you use? Well, every software > > developer I've ever met answers the same -- native assembly language for the > > processor in question. No compiled code will be more efficient because of > > the layers of abstraction that higher level languages impose. The embedded > > developers I've worked with always got a good chuckle out of their C > > language counterparts sucking up 100's of kilobytes of memory compared to > > the few K that their assembly code needed. > > But you ignore the fact that very few embedded engineers need their code > to be "as small as possible" or "fast as possible". That is because the > hardware gives lots of head room for very few bucks. Likewise FPGAs > generally are more than fast enough and large enough and cheap enough > (did *I* say that?) for 95% of the designs to be done in HDL. > In 20 years in this business (primarily telecom/datacom), I've never once had a situation where bloat was allowed. Bloat = added cost that doesn't go away. You burden every finished product with unecessary cost simply by poor design practices. A few dollars difference in parts doesn't mean much when you build 10. But when you built 100,000 it suddenly means a lot. I've had to sweat R's and C's many times, trying to remove as many as possible, and then try to make the remaining ones use similar values as much as possible -- all to try and minimize costs (cost of parts, cost of time for the person ordering different parts, cost of warehousing -- it all counts if you think about it). Having recently done an OC48 framer design (in a couple of weeks), I could have easily aimed at something like a 1C6 or 1C12 Cyclone part. Instead I aimed for a 1C3 part in the slowest speed grade. Works just fine, using about 1/3 of the LCs. A 1C3 costs 1/2 of a 1C6 roughly, yet the 1C6 is not "expensive". Choosing to design efficiently added exactly zero time penalty but yielded tremendous cost savings. > Again for the same reason that few designers do an entire project in > assembly, I won't be doing any more schematic designs. The last one I > did was a PITA to draw the gates needed for FSM design or worse, address > decoding. Data path is not bad in schematic, but the random logic is no > fun at all and it takes up so much space when you try to view a large > design. I don't mean disk space, I mean viewing space. I can view an > equivalent project in a text editor much more easily than a schematic > editor. > One startup I worked for had an embedded designer assigned to one or more ATM interface cards. These guys wrote in assembly only, and because of this were able to keep up with ATM at OC-3 rates using a very slow, primitive (i.e. inexpensive) micro. The fact that random gate design being "no fun at all" and "taking up a lot of space" suggests a few things to me. First, there are some simple rules for making a clean, legible schematic. Too bad schools never teach them. Also, I firmly believe that nearly anyone can make a functioning design given enough time. This doesn't make it a good design. Some designs are better than others, and one way to get to the "good design" stage is to get your fingers into the gates and learn how to work with them efficiently. I regularly test whether or not an HDL can create logic more efficiently than me. It can't. Not once has it implemented any type of decoding function better than I can. It can match me in terms of resources utilized, but it can't best me. By staying in the gates, I always have an instant grasp of how large a design is getting. I stopped one major piece of that OC48 design simply because it was getting too large. I knew that because I could see it on the page and in the floorplanner. Seeing the size forced me to think about other ways to implement the process. The first way worked, but so what? Not good enough. I needed to reduce the size to stay comfortably in the smaller part. > > > HDL is the same. You abstract designs (so that non-designers can pretend to > > be designers I suppose) and pay a penalty by having circuit bloat. If you > > want the smallest design possible, and want it to run as fast as possible, > > you need to use the design equivalent of assembly coding -- i.e. schematics. > > A picture is worth a thousand words, so you can make a picture or type a > > thousand words. Which one will be easier for someone else to understand, > > hmm? > > There are lots of reasons to use HDLs, but trying to enable uneducated > hardware designers (or worse, software designers) is not one of them. I > feel that to properly use an HDL you need to know what you expect for > hardware and then describe that in the HDL. But again, very few people > have to have the "smallest" or the "fastest" design. Mostly they have > goals which include schedules. > The best HDL folks I know are ones who use it like it was a schematic. So, in my mind, why bother? And again, I've never had the luxury of NOT needing the smallest/fastest design. It's how I push 4 OC48s through a $30 part, saving a client millions on NOT needing to buy a bunch of expensive ASSPs for every board. Size does count, and I can proudly say that "mine is smaller than yours". ;-) > As to the picture and word analogy, I find the words to suit design > better. It takes a large picture and a lot of time to create it, to > equal those thousand words. > Some folks are visual and some folks prefer the written word. I'm obviously visual for circuits and have no problem using the written word, like now, for example. > > > I recently talked to an FAE for an FPGA vendor. He said that fully 80% of > > the designs he has seen are done in schematics. You can even read about > > graphical versions of HDL coming out. Sounds like schematics to me. Except > > that you add a layer of obfuscation in there that will make for a more > > bloated design. Why bother? > > I don't know where you got this, but this sounds like an exaggeration. > I would say he had it backwards, but I bet the schematic usage is less > than 20%. > I got this right from the horse's mouth. I didn't make it up. It was his observation of designs he's seeing. Why would he lie? He has no vested interest in any method his clients use. Simply the stats he sees. > > An ironic thing to notice is that if you open many of the X design examples > > included with the tools, you'll see that they are schematic based. > > > > With a schematic it is sooooo simple to identify each and every flop and see > > what it is doing in a simulation. Something isn't working in HDL? Good > > luck. Oh yeah, and with schematics, you never have to do all that modeling > > nonsense. While most "designers" are modeling what their circuit is > > supposed to do, I've already got it done, simulated, verified on the bench, > > off my plate and onto the next thing. > > If you don't feel the need to simulate, then you are clearly doing very > simple designs. The simulation is to make sure you are solving the > problem rather than just knowing what you are creating. These are two > different problems. > Guess you missed it when I said I simulated the designs, right before testing them on the bench. I never skip simulating. Again though, I prefer the graphical waveform version as I get to see a nice, pretty picture of what is happening and when. It is very simple to pull up any flop in the design and see it relative to anything else. Makes debugging go 10 times faster. And, once I'm happy with it, I can transfer the simulator results back into the input file so that I can compare expected to generated results should I make changes or add new stuff. What could be simpler? > > > I was taught the power of schematics and their companion, the timing > > diagram, when I was a wee engineer pup. My first boss would sit me down and > > go over the schematics with me, asking me to justify each and every > > component on the page. If there wasn't a good reason for it, it was gone. > > Amongst the many invaluable lessons he taught me was that every component in > > the circuit should have a reason. Try doing that with an HDL abstraction. > > Most "designers" haven't a clue how that hunk of code they wrote got > > implemented in actual gates. Scott Adams would probably call them > > "Duhsigners". > > > > <getting off soapbox now> > > > > So, I'm with you 100%. Schematics rule. Xilinx has no reason whatsoever to > > support schematics, as the bloated designs that HDLs produce force folks > > into buying larger, faster speed grade parts that are naturally more > > costly. Works for them. > > > > You can always download the free Altera tools and play with their stuff. > > Fully integrated schematic capture, compiler and simulator. Very nice. Not > > perfect or bug free, but then no tool is. It is, however, VASTLY superior > > to the X garbage schematic tools. > > > > When I need to design something in an X part, I do it first in the A tools > > and use their native simulater. Then I re-enter it in X. Doing the > > drawings twice is STILL faster than doing the design from scratch in X. Try > > it. > > > > I tend to always push my clients to use A parts simply because the tools are > > so superior. Design times are radically reduced, and that saves them > > tangible money. If they insist on X parts, I revert to the paragraph above. > > > > Don't buy into the HDL propaganda. Schematics will never do you wrong. > > No, but they will take more time and make large jobs nearly impossible. For the duhsigner, perhaps. Personally, I've never found any job too large for schematics, whether doing ASICs or FPGAs. And, you need schematics to design PCBs, so the extra practice doesn't hurt. > > -- > > Rick "rickman" Collins > > rick.collins@XYarius.com > Ignore the reply address. To email me use the above address with the XY > removed. > > Arius - A Signal Processing Solutions Company > Specializing in DSP and FPGA design URL http://www.arius.com > 4 King Ave 301-682-7772 Voice > Frederick, MD 21701-3110 301-682-7666 FAXArticle: 57249
I had this error while implementing RAMs with BlockRAMs: the blockram is a componant instanciated within the coregen-generated component which in my case was wrong (dualport vs single port). I would suggest: * make sure your library is compiled before your design. * check the PORT MAP of the components VHDL is case unsensitive. IIRC Verilog is case sensitive. Santi wrote: > Hi all! > > I have a problem while trying to reuse a IP generated with the Coregen > Tool. > > I used the CoreGen (ISE 5.1) to generate my IP (everything seems ok) > and after I have reused that IP in another design using Synplify Pro > (like a black box, every thing ok, till here) and while trying to > synthesize in ISE I've got the error: > > Ngdbuild:604: logical block 'XXX' with type > 'YYY' could not be resolved. A pin name misspelling can cause this, a > missing edif or ngc file, or the misspelling of a type name. Symbol > 'YYY' is not supported in target 'virtex2'. > > I have no idea of what's going on. The IP core seems correct and the > edf/ngo files for the IP are present in the propper direcotry at > $Xilinx/coregen/ > > Some has had the same problem before? Maybe a problem with the > spelling of the ports (upper/lower case)? > > Thanks, > > Santi
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