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
Chris Carlen schrieb: > Hi: > > I have read a little about ABEL, and it seems simpler than VHDL and > Verilog. I need to learn an HDL quickly so I want to use the easiest > one, for starters. > > I need to design relatively simple logic, usually just combinatorial > glue logic, but also some asynchronous logic. > I wonder if ABELs simplicity might make it unable to express > asynchronous logic well, in which case I might be better off with a more > complex language. its possible, but why asynchronous ? ... for a really quick start and medium complexity like in CPLD design ABEL seeems very convenient to me - i like it. also nice for some glue logik with GAL like 22v10 simple description of state machines too if you think about more complex FPGA design later, you might go right away to VHDL/VERILOG Bertram -- Bertram Geiger <bgeiger@aon.at> HTL-Bulme Graz, AustriaArticle: 58526
On Thu, 24 Jul 2003 13:25:53 -0700, Mike Treseler <mike.treseler@flukenetworks.com> wrote: >Chris Carlen wrote: > >> I have read a little about ABEL, and it seems simpler than VHDL and >> Verilog. I need to learn an HDL quickly so I want to use the easiest >> one, for starters. > >ABEL is moribund. > >If you are in a hurry, use schematics. Depends what you want to do. I use CUPL (free version available from Atmel) - once you get the hang of the syntax it is very quick to set stuff up that would take forever with a schematic. However both Abel and Cupl are aimed at small PLD/CPLD type devices and you need to have a good understanding of the limitations of the target hardware to get the design to fit. If you are likely to be using larger devices, the investment in learning a more powerful and portable language may be worthwhile.Article: 58527
Hi,
I have a lot experience in programming Altera's FPGA's that's why I use
AHDL. In my humble opinion it's very easy to learn this language, but if You
want Your designs to be independent of platform I suggest Verilog and
VHDL(in this order) to use. (Almost all CAD's recognizes them).
Have a lot of fun,
Maciek
Article: 58528Hi, VHDL friends Does anyone have a synthesizable gl85, or i8085 VHDL design? I have them, but can't synthesize with leonardo or synopsis. Please reply to this address. Thank you a lot!Article: 58529
I'm trying to use/port the JTAG programmer in XAPP058, "Xilinx In-System Programming Using an Embedded Microcontroller v3.0". I use IMPACT to generate a SVF file. The SVF file is generated with no errors. Next I run the SVF file through the SVF2XSVF converter supplied with XAPP058. When I try to run SVF2XSVF.exe I get the following error: Error : Invalid SDR format [(] [2svf.svf: line 8332]:[f] I use the following command line: svf2xsvf -d -fpga -i 2svf.svf -o 2svf.xsvf -a 2svf.txt I'm running ISE 5.2.03.i Anyone know why I'm getting errors ? I've been trying to open a "Hot Line" case on Xilinx's web site but it NEVER LETS ME IN. When ever I try to log in I get: > Greg, > Your request for access is already pending approval. Please > allow 24 hours from your original request. > If you feel there has been an error, please contact > websupport_sponsor@xilinx.com I've waited a week and websupport_sponsor@xilinx.com has not gotten back to me yet. Thanks... -- Greg Deuerling Fermi National Accelerator Laboratory P.O.Box 500 MS368 Batavia, IL 60510 (630)840-4629 FAX (630)840-5406 Electronic Systems Engineering Group Work: egads_AT_fnal.gov, remove '_AT_'Article: 58530
On Thu, 24 Jul 2003 18:43:58 -0400, rickman <spamgoeshere4@yahoo.com>
wrote:
>In C programming the compiliers define constants for the date and time
>and a lot of other things that are useful information to a program. Do
>VHDL synthesis packages do the same thing?
No. I did suggest this to the committee a few years ago, but it never
got off the ground (probably on the grounds that it would have made
VHDL easier to use).
>I am looking for an
>indication of what tool is being used or what chip is being targeted so
>that instantiated components can be tailored for the brand and family of
>chip. I am sure I am not the first person to think of this.
We do a similar thing here, for similar reasons.
We define a common package containing a type which can be used to
describe the type of FPGA, e.g.
package pkg_fpga_family_type is
type t_fpga_family is (
FPGA_FAMILY_UNDEFINED, -- don't use
FPGA_FAMILY_VIRTEX_2,
FPGA_FAMILY_VIRTEX_E
-- add other types here
);
end package pkg_fpga_family_type;
Each project (i.e. project = chip) contains a unique copy of another
package "pkg_global" that is used by all modules. Pkg_global contains
a constant of a particular name of type t_fpga_family.
e.g. (in pkg_global)
constant FPGA_FAMILY : t_fpga_family := FPGA_FAMILY_VIRTEX_2;
Any module that wants to do fpga family specific stuff will contain
something like the following lines:
use work.pkg_fpga_family.all;
use work.pkg_global.all;
...
foo : if FPGA_FAMILY = FPGA_FAMILY_VIRTEX_E generate
-- do Virtex-E specific stuff
...
bar : if FPGA_FAMILY = FPGA_FAMILY_VIRTEX_2 generate
-- do Virtex-2 specific stuff
(It's also possible to pass the information in to the module via
generics instead of constants in packages.)
You quickly realise that VHDL really needs a "case-generate" and
"if-elsif-else generate" which (for some reason) were left out of the
'87, '93 and '00 standards. There's a proposal that's likely to make
it into 200X though.
The next thing you probably should do is create wrappers for your low
level components (e.g. block rams) so that you don't ever instantiate
a "raw" block ram in your application code; you just instantiate the
wrapper. The wrapper will hide all the details of fpga_family from
you. When you want to add a new fpga_family value, you only have to
edit the wrapper. (You can also include "value added" features such
as a selectable pipeline delay on the output, etc.)
This has an unexpected side-effect - you can easily add simulation
models to the wrappers (selected by a generic that's only set during
simulation) that behave the same way, but run faster. We typically
get a 2:1 to 5:1 simulation speed up this way. (The Xilinx Unisim
library uses VITAL and is *slooow* compared to an RTL simulation.)
I hope this helps.
Regards,
Allan.
Article: 58531
Hi,
Maybe I lately spend too much time with computer and sleep too little so
I stopped thinking , but I have following problem.
I'm using now Altera Quartus Web Edition 3.0 free version in academic
project. In my project I use lpm ram component. When I used MaxPlus+II I was
able to specify Memory Initialization File(mif) during the simulation. Now
with Quartus I also can create mif files but I can't find out how to
associate them with memory components in my project. During the compilation
I obtain warning message: "Warning: Memory Initialization File or
Hexadecimal (Intel-Format) File for RAM is not specified -- setting initial
contents to 0" and that's all.
I don't know where is the problem - maybe in me, or maybe free version of
Quartus have some limitations.
Thank You for Your help,
Maciek
Article: 58532please, forgive me, it was so obvious... MaciekArticle: 58533
I think you've asked this question before, perhaps a month or two ago. As with the last time, it isn't clear what you are trying to do. Do you have 16 separate inputs at 16 MHz each? If so, cramming 256 MHz worth of data into a 155 MHz pipe is a neat trick, but not one a TEMUX can do. Or an FPGA for that matter. You can cram 2 signals at 16 MHz into one DS3 rate signal, but 3 at 16 MHz = 48 MHz, and therefore won't fit. Using this math, the best you could do is cram 6 signals into 3 DS3's, which could fit into a 155M signal. Without doing much math, I think you can cram maybe 9 of these 16 MHz signals into a concatenated 155M pipe. But, then again, it isn't clear what you are trying to do or how you are carving up the data. Are you selecting some subset of the 16 inputs to feed through the STM-1 pipe? If so, how many max? What is the clock tolerance on the 16 MHz signals? Can you provide any additional detail? "Masoud Naderi" <naderimisc@yahoo.com> wrote in message news:2ba3bbea.0307241443.3ba8845b@posting.google.com... > Hi all, > I want to use PMC-Sierra chipset for my STM-1 card. Input to this card > is 16x16Mhz sync channels that comes from backplane. I can use > PMC_TEMUX chip(pm8316) to make 3xDS3 PDH channel and feed them to > PMC_SPECTRA chip (PM5342). But it seems using PMC_TEMUX chip is not > cost saving and not suitable for this design, because TEMUX can do > many things that wont use in this application. I think making DS3 > signals from backplane signals (16Mhz) can be done easely in FPGA, so > bypassing TEMUX chip. It should be noted that single or multi E1 > channels should be extraced from our output STM-1 signal (for example > from an ADM in SDH ring). > Please help me in this regard. > Regards. > M. NaderiArticle: 58534
Egads, You may want to make sure you have the latest build of iMPACT(5.2isp3) and SVF2XSVF(5.11 build) converter. Also, you can contact the hotline by phone as it's likely that you'll have to submit your files for further investigation. Regards, Wei Xilinx Apps Egads wrote: > I'm trying to use/port the JTAG programmer in XAPP058, "Xilinx > In-System Programming Using an Embedded Microcontroller v3.0". > > I use IMPACT to generate a SVF file. The SVF file is generated > with no errors. Next I run the SVF file through the SVF2XSVF > converter supplied with XAPP058. When I try to run SVF2XSVF.exe > I get the following error: > > Error : Invalid SDR format [(] > [2svf.svf: line 8332]:[f] > > I use the following command line: > > svf2xsvf -d -fpga -i 2svf.svf -o 2svf.xsvf -a 2svf.txt > > I'm running ISE 5.2.03.i > > Anyone know why I'm getting errors ? I've been trying to open a > "Hot Line" case on Xilinx's web site but it NEVER LETS ME IN. > When ever I try to log in I get: > > > Greg, > > Your request for access is already pending approval. Please > > allow 24 hours from your original request. > > If you feel there has been an error, please contact > > websupport_sponsor@xilinx.com > > I've waited a week and websupport_sponsor@xilinx.com has not gotten > back to me yet. > > Thanks... > > -- > Greg Deuerling > Fermi National Accelerator Laboratory > P.O.Box 500 MS368 Batavia, IL 60510 > (630)840-4629 FAX (630)840-5406 > Electronic Systems Engineering Group > Work: egads_AT_fnal.gov, remove '_AT_'Article: 58535
Symon, No, I love the idea, and I have recommended it to the folks that do that kind of stuff. Unfortunately, it goes in the same pile at all of the other IP requests, and then it gets looked at for how it adds to the bottom line (we are a business, after all). Like any other claim from the "competion," our first reaction is not "oh my, the sky is falling" primarily because the claims are often inflated. Rather, we look at the feature, and decide if it is worth the effort/business to match/exceed it. Austin Symon wrote: > Of course, use MicroBlaze! Good one, John, works for VirtexII and Pro. > Does SpartanIII have ICAP? Can't see it in the datasheet I have. Any > idea of the resource needed for a MicroBlaze and a UnZip program? > It seems to me that Xilinx might want to implement this for us. > They get to use a known compression standard, Zip, supported by > everybody's computer, so customers can see the likely compression > ratio results.(Up to 5:1 according to Ray's post.) They can showcase > their MicroBlaze, Partial Reconfiguration, ICAP. They beat their > competition's 35% to 60% compression, using a soft, programmable, > retrofittable solution which FPGAs are all about in the first place. > What about it Austin? Are you worried about plunging sales of the > config PROMs? ;-) > cheers, Syms. > > John Williams <jwilliams@itee.uq.edu.au> wrote in message news:<bfn953$bl7$1@bunyip.cc.uq.edu.au>... > > Symon wrote: > > > Austin, > > > Glad you like the idea. Out of curiosity I tried WinZipping some > > > bit files and got >90% compression on my admittedly only 10% full V2 > > > design. So, I await the first freebie port of WinZip to VHDL or the > > > PPC. I won't be holding my breath!! > > > > zlib builds cleanly for microblaze with mb-gcc - it would be very simple > > to write a simple microblaze program to decompress a bitstream file. > > > > The trick would be interfacing the microblaze to ICAP and and pumping > > the bits. As long as the new (decompressed) bitfile didn't overwrite > > the microblaze that was actually doing the decompression, you'd be off > > and running. If you eventually used the microblaze in your "final" > > design then this would be quite a neat way to go. > > > > Regards, > > > > JohnArticle: 58536
Symon, I suppose we are in violent agreement on this issue (ie the soft core is a great solution). We have already gone and asked "how much money/business do we get (incrementally) if we have bitstream compression?" Guess what? It is pretty tiny. So let me clue you in on something: with the costs of memory always falling like crazy, and the costs of developing anything reliable of high quality being always pretty high ($$$), what do you think the probability of us releasing the soft core that unzips the bitstream? Now, maybe next summer's interns.... If someone out there developed it, maybe someone would pay for the IP? Heck, if someone really wants to do this for Spartan 3 (ie serious with business), email me directly, and I will find out about the "hidden" features (if it is possible or not, and how much hacking is required). Austin Symon wrote: > Hi Austin, > On the other hand, I'm sure every one of those 150k designers > understands that compression ratios aren't guaranteed. It doesn't stop > us all using .zip files, does it? Just another tool in the designer's > armoury! Furthermore, Xilinx already offers bitstream compression on > an unused frames basis, so I don't really follow your argument that > Xilinx needs to give a compression guarantee before offering this > feature? > So, doesn't the soft solution we're discussing here solve the > arguments against providing better compression? I'm sure loads of > folks would appreciate this feature. Why not get your marketing to ask > some of them? Also, why not try running WinZip on some of the many > sample designs you have, and let us know the results? > I guess a cynic might say that because vendor A started offering > compression, the official vendor X stance is that it's not needed. Not > me though, I trust you guys have our best interests at heart!! ;-) > All the best, Syms. > > p.s. I chuckled at the 'wonderful downloading experience' bit! Over > the years my downloading experiences have often been somewhat less > than 'wonderful'! Frustrating, temperamental, even infuriating! I > guess I only remember the bad ones, I must admit things seem to have > improved recently. Must go smoke my 'Done Pipe'! ;-) > > Austin Lesea <Austin.Lesea@xilinx.com> wrote in message news:<3F1FF59D.BE7CA90D@xilinx.com>... > > Ray, > > > > We routinely get folks who say they can compress a particular bitfile by 5:1 or even 10:1. > > > > Too bad that doesn't hold true for all bitfiles. > > > > As I have said before, if there was a good way to guarantee compression, we would have done it years ago. > > > > Let's see, we have ~150,000 bitstreams that are being developed right now at this moment. Think about > > it: to remain a quality supplier we have to make every one of those 150,000 designers have a wonderful > > (downloading) FPGA experience. Just one flakey option bit in the bitgen, and the hotlines would meltdown. > > > > Austin > >Article: 58537
Mike Treseler wrote: > Chris Carlen wrote: > > > I have read a little about ABEL, and it seems simpler than VHDL and > > Verilog. I need to learn an HDL quickly so I want to use the easiest > > one, for starters. > > ABEL is moribund. > Abel is very much alive, as part of our (free) Webpack and iSE products. We have even made a few enhancements in the last few years, such as improved FSM optimization. However, it is only supported for targeting Xilinx CPLDs. So if you are doing this for educational reasons, you probably want to go with one of the two "V" languages - Verilog or VHDL (hint: of the two, Verilog is generally considered to be the easier to learn, unless you happen to already know Ada). There is a body of opinion, both inside and outside of Xilinx, that for crafting tight, small CPLD designs, Abel is superior to VHDL/Verilog. Semantically, it is much closer to an assembly language, allowing you to specify exactly what you want your implementation to be. An easy way to compare the languages is to look at the jc2 design examples shipped with Webpack. It comes in Abel, VHDL, Verilog and schematic variants. My $.02, Dennis McCrohan Xilinx CPLD S/WArticle: 58538
Hi Jim,
No worries! I'd be grateful if you let me know how you get on,
it's a useful feature!
thanks again, Syms.
"Jim Robinson" <jim@synplicity.com> wrote in message news:<42ZTa.28599$Nf.74228@sea-read.news.verio.net>...
> Hi Symon,
>
> Sorry that is missed that. I was focused on the problem flop and
> was not paying attention to the counter.
>
> Since it appears that you have a work-around in place (toggle as
> std_logic_vector),
> I will shift my attention towards working with our development team to
> diagnose the bug and schedule a fix.
>
> My appologies for not providing you with a more useful work around. Let me
> know if you encounter any other difficulties.
>
> Best Regards,
> Jim Robinson
>
>
Article: 58539Global reset is obviously a good thing, but it also has a problem: What happens after the trailing edge of global reset? Cab you take away the global reset "simultaneously" from all affected circuits, and if you cannot, what happens when one circuit stays in reset a few clock ticks longer than the others ? All Xilinx FPGAs have a built-in global reset that gets released at the end of configuration, and that release can also automatically be internally synchronized with the user clock. Inspite of this, at high clock rates some state machines may need individually resynchronized reset. This has been discussed in many threads in this ng. Peter Alfke, Xilinx ApplicationsArticle: 58540
Hi Yevgeny, I can make two suggestions here. > > How can I make NIOS to wait for the "ready" from the arbiter? > I think I've tryed every signal there : "dataready", "dataready_n", etc... > First, with regards to the current implementation you are attempting: The key here is which signals Nios responds to for delaying or waiting for a bus transaction. It sounds as if you're using a 'ready' signal and connecting it to type 'dataavailable' (avalon signal type) in the SOPC Builder wizard. The dataavailable signal, like its counterparts 'endofpacket' and 'readyfordata' are the three "Streaming" signals supported by Avalon. As per the Avalon Bus Spec, not all masters heed these 'streaming' signals. For example, the Nios CPU doesn't, while the DMA controller does. The simplest solution to your current implementation attempt is to use a signal that Nios (and all avalon masters) must respond to: the waitrequest signal. Waitrequest is just that. When a master attempts a bus transfer with a slave, it is locked waiting until the slave negates waitrequest. I would caution you to ensure that your logic negates waitrequest, as a logical error that would leave it asserted would hang the CPU (or any other master) attempting access. > > Or maybe there is a way to configure NIOSes SDRAM controller to support > two NIOS CPUs instead of using that external arbiter? > The second thing I can suggest, and would recommend, is to make use of our own bus arbitration logic. You can in fact connect two (or more) masters (two Nios', DMA, your own custom master, another microprocessor) to any avalon slave, including the SDRAM controller. The 'external' arbiter you refer to, our own Avalon bus logic, automatically wires everything up. However, beyond this it also allows you to balance the priority (using a fairness-based arbitration scheme) for anytime more than 1 master requests the same slave. For the case of two CPUs talking to shared SDRAM, I'd suggest giving each an arbitration assignment high enough to allow several pipelined accesses by each CPU, allowing higher throughput (perhaps 16/16, 32/32, or something similar). I suggest checking out Altera App note 189 for a brief overview of how this is implemented. Please note that for optimal performance, I would also recommend that you use the enhanced (SDR) SDRAM controller included with the Nios 3.0 (or higher) release. Regards, Jesse Kempa Altera Corp. jkempa at altera dot comArticle: 58541
Hi,
The problem with a global reset can occur if,
a) the reset is asynchronous
b) there are synchronous elements in the design clocked by clocks
different from the one that's synchronous with the reset
If the global reset is cleared at the same time as, for example, a
flip flop is being clocked, then you might encounter metastability
problems, or state machines being initialised into illegal states.
Try reading the TechXclusive by Ken Chapman on the Xilinx site
called "Get Smart About Reset (Think Local, Not Global)". He describes
it better than I can!
Cheers, Syms.
"Martin Euredjian" <0_0_0_0_@pacbell.net> wrote in message news:<f45Ua.3778$Si5.3166@newssvr22.news.prodigy.com>...
> I'm not disputing the need for reliable reset. From what I've read on this
> N.G. the GSR approach does not seem to be the recommended way to go.
>
> On my current design I implement an "intelligent" global reset module that
> issues reset signals to various portions of the design and verifies that the
> module being reset is OK before moving forward. For example, the DCM's need
> to be checked for lock before allowing related modules to even think about
> intializing, much less operating. I also have several modules that set a
> flag when their state machine enters the "RESET" or "INIT" state. The reset
> generator looks for this flag as confirmation that the particular module is
> OK. Since my design requires modules to be reset/released-from-reset in a
> specific sequence this works very well. There are modules that have their
> own reset or startup requirements.
>
> I guess I now think of an external reset signal as just another input that
> triggers actions (in my case a state machine) as opposed to the reset inputs
> of all the flip-flops within the FPGA.
>
> Are you saying that it is OK to rely on a global reset signal that is
> directly connected to all flip-flops within the FPGA? Again, reading
> through the N.G. archives the experts seem to agree on that this is
> potentially dangerous.
>
> I only have experience with Xilinx Virtex II, so my field of vision is
> seriously impared.
>
>
> --
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Martin Euredjian
>
> To send private email:
> 0_0_0_0_@pacbell.net
> where
> "0_0_0_0_" = "martineu"
>
>
>
>
>
Article: 58542If you ignore Trolls they usually go away! "Martin Euredjian" <0_0_0_0_@pacbell.net> wrote in message news:<IL4Ua.3776$3o5.1223@newssvr22.news.prodigy.com>... > > seannstifler69@hotmail.com (Stifler) wrote: > > ... > >> Why are you vendors even on this board? Who believes all of your spew? > ... >Article: 58543
history has shown price of the same part go down year over year, and there is no fixed percentage you can attach since it depends upon a lot of factors...and the price may become flat at certain point in time wherein the part is considered "mature". How much time? Again, too many factors, and pretty evident that this time is shrinking...and so is the time when an end-product actually remains in demand... always better to be able to embrace newer technologies to get a quantum cost reduction... --neeraj "MS" <wpiman@aol.com> wrote in message news:f0ddfdfb.0307231511.41556904@posting.google.com... > Hi, > So we are looking to implement some functionality that we have done in > NPUs in the past into a Xilinx Virtex2Pro family (small space and less > power). > > These parts are quite expensive right now (up to $1500 a piece). Our > build timeframe is starting next year, carrying out into 2006/2007. > When you add up the cost of product- the budget is nearly consumed > completely by the FPGAs. > > The question is how much do you usually expect FPGA prices to fall in > a given year. For example, would a guess of a 15% drop in the first > year followed by a 30% fall in the second year be a good stab? 20% a > year? I just need to fill out some numbers to make some bean counter > happy. Anyone take a look at what has historical been the price > drops? > > Thanks, > M ScottArticle: 58544
You guys are right, there's no need for an external reset on power up. Using the GSR to reset my state machine and start the whole thing is the simple solution. thanks "Martin Euredjian" <0_0_0_0_@pacbell.net> wrote in message news:uQ3Ua.3774$m%4.3163@newssvr22.news.prodigy.com... > Why is it that you want to reset the FPGA after configuration? For all > intents and purposes it is coming out of reset after configuration. > > If you need to do so in order to wait for an event build that into a startup > state machine. > > If you need to guarantee that other portions of the board are ready you can > also build that into a startup state machine. > > If you need to ensure that certain flip-flops and logic come-up in a > specific state you can do that through the bitmap itself. > > I've read quite a bit about global reset not being a reliable approach. Do > a Google search of this N.G. using "GSR". Imagine flip-flops in different > portions of the design coming out of reset at slighly different times. Or > maybe even flip-flops holding the state of a state machine. I believe I've > experienced this first hand (not using GSR, but my own global reset) and it > wasn't fun to debug, it took longer than I care to admit to figure out what > was going on. > > > -- > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > Martin Euredjian > > To send private email: > 0_0_0_0_@pacbell.net > where > "0_0_0_0_" = "martineu" > > > > "..:: Gabster ::.." <gabsterblue@hotmail.com> wrote in message > news:Vy2Ua.10962$Fo3.164756@weber.videotron.net... > > Hi, > > > > I want to use a simple reset circuit to reset my FPGA, but I'm unsure > > how to handle it because of the PROM. The point is the PROM has to program > > the FPGA before the FPGA is reset. How the reset circuit could to be > > implemented considering this. I was thinking about a reset circuit with a > > built-in delay, but I'm sure there's a easier way to do it. > > > > thanks, > > Gabriel > > > > > >Article: 58545
Here's a nice link:-
http://www.emcesd.com/1ghzprob.htm
Nice piccies!
Also :-
http://www.sigcon.com/
HTH, Syms
"Peter C. Wallace" <pcw@freeby.mesanet.com> wrote in message news:<pan.2003.07.24.23.29.19.599163.15416@freeby.mesanet.com>...
> On Thu, 24 Jul 2003 16:04:20 -0700, Peter Alfke wrote:
>
> > Howard Johnson once gave me a nice tip: Use a 50 Ohm cable driving a 50
> > Ohm-terminated input to the oscilloscope. Then solder a 470 Ohm resistor
> > to the cable front end, and you have a 10:1 passive probe with GHz
> > bandwidth. Doesn't make the scope any faster, but avoids the loss of
> > bandwidth in the probe. You pay for it by throwing away a factor 10 in
> > sensitivity, and you load the circuit under test with 520 Ohm, but both
> > these restrictions are acceptable, most of the time...
> >
> > Peter Alfke
> > ===================
>
>
> Plus 520 Ohms resistive load is a lot better for pulse fidelity than the 159
> Ohms capacitive reactance of a 10 PF scope probe at just 100 MHz...
>
> PCW
Article: 58546Dennis McCrohan wrote: > Mike Treseler wrote: > > >>Chris Carlen wrote: >> >> >>>I have read a little about ABEL, and it seems simpler than VHDL and >>>Verilog. I need to learn an HDL quickly so I want to use the easiest >>>one, for starters. >> >>ABEL is moribund. >> > > > Abel is very much alive, as part of our (free) Webpack and iSE products. We > have even made a few enhancements in the last few years, such as improved FSM > optimization. > > However, it is only supported for targeting Xilinx CPLDs. So if you are doing > this for educational reasons, you probably want to go with one of the two "V" > languages - Verilog or VHDL (hint: of the two, Verilog is generally considered > to be the easier to learn, unless you happen to already know Ada). > > There is a body of opinion, both inside and outside of Xilinx, that for > crafting tight, small CPLD designs, Abel is superior to VHDL/Verilog. > Semantically, it is much closer to an assembly language, allowing you to > specify exactly what you want your implementation to be. > > An easy way to compare the languages is to look at the jc2 design examples > shipped with Webpack. It comes in Abel, VHDL, Verilog and schematic variants. > > My $.02, Thanks for the input. A lot of conflicting responses. It might be that the investment of effort to learn to do my relatively simple projects in ABEL, will not be wasted. I can always look at one of the V languages later. It is good that Webpack includes an example which is implemented in all four methods. I will check it out. Good day! -- _____________________ Christopher R. Carlen crobc@earthlink.net Suse 8.1 Linux 2.4.19Article: 58547
Jack,
http://www.xilinx.com/xlnx/xweb/xil_tx_home.jsp
Relationally Placed Macros
HTH, Syms.
bymanaar@hotmail.com (Jack Stone) wrote in message news:<6ba79926.0307250028.331f0d58@posting.google.com>...
> This question may have been asked before but ...
>
> I often have timing problems when using virtex-II dedicated
> multipliers. After synthesis/P&R I have fixed these by looking at the
> placement with ISE floorplanner and then constraining the multipliers
> and their i/o registers to be packed as close together as possible.
> This requires too much effort for this lazy engineer. I must be
> possible to do this constraining in my VHDL code via attributes. How?
> Does anyone have a bit of example code?
>
> I don't really want to place the multiplier in any certain spot,
> rather just make sure that the registers holding its input and
> catching its output will be placed in the adjacent slices...
>
> Thanks in advance for your help.
Article: 58548Hi Andrew, All 16Mhz signal on backplane have the same clock and frame sync. signal, i.e. ALL of them are sync together with the same clock. Anolog problem like jitter, crosstalk, skew or other things is not of my concern, because they are solved in a different designing layer. In my design layer ONLY chipset (functionality, cost, chipset reliability and ...) is important. My STM-1 card has two STM-1 (155M) Port. 8x16Mhz signal feed to each port's chipset. Not all of time slots in 8x16Mhz go to output ports. Some of them used for board and chipset housekeeping and remote configurations. I find the answer of my first question: Is it possible to make 3xDS3 signal from 8x16Mhz(SYNC) backplane channel by FPGA and feed them to PMC_SPECTRA? The answer: Yes, it is possible, DS3 framing in FPGA is not so hard because all channels are synchronous together. In receive side from PMC_SPECTRA FPGA must extract, for example 21xE1 signal from 3xDS3 lines, synchronize all of them to one clock signal and convert them to 16Mhz backplane signal format. the later step is not so easy in all configuations of PDH signals insides DS3s. Conclusion: In current design phase I use PMC_TEMUX + PMC_SPECTRA + Micro (FLASH+RAM+MICROPROCESSOR+HDLC CONTROLLER)! Embedding temux and micro section in FPGA will be for next version. Hope this gives a clear perspective of my views, If not please let me know. Best Regards. Masoud Naderi Andrew Paule <lsboogy@qwest.net> wrote in message news:<Wt2Ua.177$TT2.87277@news.uswest.net>... > Hi Masoud - > > this should in theory be pretty easy, but you need to quantify many > things befor the decision is made - 16MHz may be pretty slow, but is > there a channel to channel synch requirement - crosstalk - jitter - > others? Decision should have more data for a basis than is here ( I > would guess that there is). I could easily put enough nitrous into my > car so that the motor was capable of taking it into the 8's in a quarter > mile, but the tranny certainly would not take it, and I'd probably > twist the crank if nothing else. > > Andrew > > Masoud Naderi wrote: > > >Hi all, > >I want to use PMC-Sierra chipset for my STM-1 card. Input to this card > >is 16x16Mhz sync channels that comes from backplane. I can use > >PMC_TEMUX chip(pm8316) to make 3xDS3 PDH channel and feed them to > >PMC_SPECTRA chip (PM5342). But it seems using PMC_TEMUX chip is not > >cost saving and not suitable for this design, because TEMUX can do > >many things that wont use in this application. I think making DS3 > >signals from backplane signals (16Mhz) can be done easely in FPGA, so > >bypassing TEMUX chip. It should be noted that single or multi E1 > >channels should be extraced from our output STM-1 signal (for example > >from an ADM in SDH ring). > >Please help me in this regard. > >Regards. > >M. Naderi > > > >Article: 58549
Martin Euredjian wrote: >Vikram Pasham <Vikram.Pasham@xilinx.com> wrote: > > > >>MPPR is used when PAR fails to meet timing constraints by a small margin with >>the default cost table. Each cost table would serve as a seed for PAR algorithm >>and result in a different placement and routing. One of these results may meet >>your timing constraints, otherwise MPPR will indicate the best placement and >>routing it achieved with the given cost tables. >> >>In your case all these MPPR results meet your timing constraints, as the timing >>score is zero. Timing score is simply a summation in picoseconds of all timing >>violations. You can use any of these cost table as long as your timing >>constraints are met by PAR. The following solution record explains on how to >>interpret MPPR report >> >> > >Thanks for your post. This much I knew, for it is available >information in the documentation. > >My question had to do with the procedure to follow after running MPPR. > Somewhere I saw a blurb about going back to P&R and running it in >"Re-entrant" mode. > This would be for the case where none of the cost tables met your timing constraint. You would take the one with the lowest timing score and run re-entrant route on that ncd. > But, I couldn't find what this really means and >how it uses the results of MPPR. It seems to me that the easiest >procedure is to simply re-run P&R with the best seed table (per the >MPPR report). > There is no reason to rerun PAR becaue you already have the NCDs. If the timing score is 0, the only way to tell which one is best is with the design score. The design score was created about 12 years ago for the XC3000 family and although it might be some indication of which table is best, it probably will not match the criteria you might say is best for your design. In addition, just because one table is the best for your current design does not mean it would be the best if you made a minor change to your design. > Is that pretty much the extent fo the relationship >between MPPR and P&R? > The relationship is that if you run MPPR on 3 cost tables, then ran PAR on table 1, then 2, then 3, you would have the same results. The way you use it is for cases when your design does not route or does not meet timing running PAR. The, you would run MPPR to see if it can meet timing running multiple cost tables. If it doesn't, but gets close, then you take the best one and run re-entrant route. Steve > >Thanks again, > >-Martin >(posting from hotmail 'cause sbc/pacbell usenet servers seem to be in >dire need of maintenance or exorcism) > >
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