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
Pete Dudley <padudle@sandia.gov> schrieb in im Newsbeitrag: 384E6E34.77FB@sandia.gov... > Holger Kleinert wrote: > > > > Bernard Esteban <esteban@worldnet.fr> schrieb in im Newsbeitrag: 82iq91$kpp$1@wanadoo.fr... > > > Hi, > > > > > > Where can I find information how works JTAG signals on PC mother board ??, > > > the goal, is to check if a PCI card with JTAG devices is well connected with > > > on PCI slot. The JTAG connector is on PCI card. > > > > JTAG is an optional feature of the PCI System. > > The interfacing for this signal on a mainboard is vendor dependent. > > Also the boundary scan order is vendor dependent. > > I found no information regarding this manner in the PCI Spec V 2.2. > > > > I guess the PCI-JTAG is most used for product verification during factory assembly. > > -- > > mfg > > Hollgi > > http://www.hollgi.de > > > My guess is that the JTAG signals on the PCI connector are never used by > anyone for testing. JTAG is a very complicated and slow way to test. Ohh , that doesn't matter if only approx. 100 connections from any JTAG Compliat PCI device to the slot have to be tested against soldering problems.. I know this takes just a second... > > On the other hand the JTAG signals on a PCI card could be very useful > for programming In System Programmable (ISP) devices. Good idea :-) Holger http://www.hollgi.deArticle: 19251
Apologies to everyone, this message is for the original poster,
Utku Ozcan, only.
Utku:
I tried replying to your private email using this address:
Utku Ozcan <ozcan@mimoza.netas.com.tr>
I got the following error message:
> This report relates to a message you sent with the following header fields:
>
> Message-id: <4.2.0.58.19991208155226.00a3fd40@popgtw.fnal.gov>
> Date: Wed, 08 Dec 1999 15:52:53 -0600
> From: Don Husby <husby@fnal.gov>
> To: Utku Ozcan <ozcan@mimoza.netas.com.tr>
> Subject: Re: Problems with routing Virtex device
>
> Your message cannot be delivered to the following recipients:
>
> Recipient address: ozcan@mimoza.netas.com.tr
> Reason: Illegal host/domain name found
--
Don Husby <husby@fnal.gov> http://www-ese.fnal.gov/people/husby
Fermi National Accelerator Lab Phone: 630-840-3668
Batavia, IL 60510 Fax: 630-840-5406
Article: 19252On Wed, 08 Dec 1999 21:47:25 +0200, Utku Ozcan <ozcan@mimoza.netas.com.tr> wrote: >Design Entry: Verilog >Synthesizer: Synplify v5.21 >P&R: Design Manager M1.5 patched >Technology: XC4044XLA > >We have two clock domains, 25 MHz and 6 MHz, and 25 MHz is derived >internally. Two separate FSM's in different clock domains communicate >to each other. Since implementation is quite fast, we directly perform >postroute simulations. > >The problem is, that FSM's can't talk to each other in lab. FSM's are >alike, they have 1-bit states, at every execution the states are expected >to toggle, 0-1-0-1..., as we have seen at postroute simulations. > [other stuff deleted] Can you post your Verilog? Bob Perlman ----------------------------------------------------- Bob Perlman Cambrian Design Works Digital Design, Signal Integrity http://www.best.com/~bobperl/cdw.htm Send e-mail replies to best<dot>com, username bobperl -----------------------------------------------------Article: 19253
SynaptiCAD supports OPENCORES Initiative with Free HDL Simulators and Test Bench Generators. Press release is available online at http://www.opencores.org/press/press_release_9dec1999.shtml regards, OPENCORES.ORG teamArticle: 19254
> On the other hand the JTAG signals on a PCI card could be very useful > for programming In System Programmable (ISP) devices. I can't figure out how to take advantage of that - at least in the general case. How are you going to decide which bits to load? Remember, if this idea takes off everybody else will use it too. So you have to be able to figure out what type of card is plugged into that slot before you have loaded the logic. If you could read the PCI device ID register then the card would be working, at least somewhat, so you are just loading some non-PCI logic and you can use the PCI connection to do that. Am I missing something? I assume it would work fine is a special case where you knew which cards were in which slots. -- These are my opinions, not necessarily my employers.Article: 19255
Well, you really need to divide by max 800,000 with a 20-bit counter. The easiest way to divide by selectable numbers is to implement a synchronously loadable 20-bit down counter, which takes 11 CLBs in XC4000. You then use the overflow signal to signal the time-out. The binary load value determines the delay. Since you start with 8 MHz and want a min resolution of 1 microsecond, you load zeros into the three LSBs. If you prefer an up-counter, then you must load the complement of the desired time. The design is really trivial, since it uses the dedicated carry logic in XC4000. Peter Alfke, Xilinx Applications ======================= muzo wrote: > Moussa Ba wrote: > > Good Day, > > What is the best to way to implement a Delay ranging from 1us to 100ms, > > I am synthesizing some verilog code for use with a xilinx xs4005xl. > > Could you please direct me to the best code construct for implementing > > such a delay. The clock in my design is 8MHz and I am using Xilinx > > Foundation 1.5 software. > > > > Thank you in advance > > I will take the trivial interpretation of this question and try to > answer it. > If you need a single programmable delay you can use a single > synchronous counter and reset it to overflow at different numbers to > implement the delay. 8 MHz has a 125 ns period so you need a counter > from 8 to 10e5 which a 17 bit counter can do. You can register the > signal you want to delay everytime the counter overflows. If you want > multiple delays of fixed size, you can do a ripple counter (you don't > want many 17 bit counters because of size) and divide 8 MHz into > smaller speeds. The you can pick the outputs of some of registers in > the ripple counter to drive much smaller synchronous counters the size > of which depends on the precision you need in the delay. > > Hope this helps. > muzo > > Verilog, ASIC/FPGA and NT Driver Development Consulting (remove nospam from email)Article: 19256
In article <82mt61$sld@src-news.pa.dec.com>,
Hal Murray <murray@pa.dec.com> wrote:
>How are you going to decide which bits to load? Remember, if
>this idea takes off everybody else will use it too. So you have
>to be able to figure out what type of card is plugged into that slot
>before you have loaded the logic. If you could read the PCI device
>ID register then the card would be working, at least somewhat,
>so you are just loading some non-PCI logic and you can use the
>PCI connection to do that.
>Am I missing something?
>I assume it would work fine is a special case where you knew
>which cards were in which slots.
Assume that you only ever add or move cards of one type for each reboot.
The device driver knows which slot no. the card is supposed to be in (the
first guess is slot 0). If the card does not appear to be in that slot, the
driver uploads to each slot which appears blank until it finds the card, and
records the slot no. where it finds the card. This reduces configuration
time too, since after the card is installed, the driver will try only the
correct slot.
Of course there will be havoc if there are multiple people using this scheme
and the user decides to upgrade his motherboard (in which case cards of
different types have to be configured).
A simple standard we should try to agree on is a two-stage FPGA
configuration process. For stage one we upload a tentative configuration
which keeps all outputs tri-state except for a few which communicate with a
tiny serial flash prom which contains a copy of the card id. Once the card
is verified, stage two is commenced: the FPGA is reconfigured with the
application. When a driver is looking for its cards, it is permitted to
reconfigure cards which are in stage one. Perhaps a good place for this
prom is the M1, M2 and M3 lines which can double-up as I/O (at least for
Xilinx FPGAs).
To configure the addresses after the normal PCI configuration, just subtract
the amount your card needs from the lowest addressed PCI card in the system
(ignoring anything which appears below the end of RAM), and use it. Anyway
this works for the special, but very important case of Windows-95/NT/Linux
on a PC.
I actually don't use JTAG pins (I don't know how or even if they work
through PC PCI controller chips). Instead I have a little discrete-logic
circuit which latches some low order configuration write address bits (which
get through even if there is no devsel response) when the configuration
write is to a high and otherwise unused area. The output of this latch
feeds CCLK, DIN and NPROG. This circuit is resistor isolated from the PCI
bus so that it does not add too much extra load.
Unusual FPGA configuration is an amusing subject. I know someone who made a
macintosh video card which was composed of an XC2064-50 (the first, smallest
and slowest fpga!), 4 DRAM chips and a crystal. Period. Now this was for
the original macs which didn't have add-on slots- the card was designed with
a "Killy-clip" which would clip onto the 68000 microprocessor pins. I don't
know which CPU signals they used for configuration (parallel mode I guess
and extra address lines for chip select), but somehow they made this thing
work and sold a bunch of them (including the high res. 19" monitor which
went along with it).
Another configuration method which I find to be convenient is to use a
74LS123 dual one-shot (or a couple of 555s) for a clock separator for RS-232
serial. The start bit triggers one one-shot. When that times out, the
second is triggered which generates the CCLK pulse right in the middle of a
9600 baud frame. The software sends FFs and 00s over the serial line to
configure the FPGA. I modified a Medicaid point of sale device (basically a
credit card reader) by adding one fpga, a crystal, the 'LS123 some
transistors and a DB9 connector so that I could read the vacuum fluorescent
display and simulate keypresses with a separate PC. The purpose was to
automate the eligibility verifcation process for a methadone clinic (they
have to verify each patient every day and this was the only way to do it- it
was actually one person's entire job to do this). The hard part was that
the EDS P.O.S. device had two circuit boards sandwiched together (and which
you want to separate when you dissassemble the thing). One had the battery
and the other had the RAM which contained the program for the device.
Anyway this was easier than hacking the protocol.
--
/* jhallen@world.std.com (192.74.137.5) */ /* Joseph H. Allen */
int a[1817];main(z,p,q,r){for(p=80;q+p-80;p-=2*a[p])for(z=9;z--;)q=3&(r=time(0)
+r*57)/7,q=q?q-1?q-2?1-p%79?-1:0:p%79-77?1:0:p<1659?79:0:p>158?-79:0,q?!a[p+q*2
]?a[p+=a[p+=q]=q]=q:0:0;for(;q++-1817;)printf(q%79?"%c":"%c\n"," #"[!a[q-1]]);}
Article: 19257I am just starting to look at incorporating the Lattice reprogrammable parts like the ispLSI1016E or maybe some of the bigger parts, but I am wondering just how secure they are, once the fuse is blown. Since even with a blown security fuse, they can be erased and reused....is it really all that secure? The programs they provide (e.g. the Daisy Chain Download program) can't read a secured part, but is this a case of the part being impossible to read, physically, or is someone going to be able to read it with relative ease, given proper knowledge and tools? Would I be ahead using a different type of part for better security? TIA, Jeff SmithArticle: 19258
Subject tells the story. We have started to have a lot of problems lately programming Altera devices through JTAG. We have both a "BitBlaster" (serial interface to JTAG port) and a ByteBlasterMV (parallel port interface to JTAG). We have had a wide range of problems on many different designs. The common thread is that the device fails to program and MAX-Plus either reports that the device is unknown, not installed, JTAG chain is bad, or else does an examine/program and then fails with verify errors. In the latter case, we can often get exactly the same # of verify errors each time. This happens with two different computers, a couple of different versions of MAX-Plus, and both the BitBlaster and the ByteBlasterMV. It also happens with both single EPLD systems and cards that have five devices in a chain. The only common thread is that the problem seemed to start when we started using MAX7000A's, although it sometimes happens with 7000S devices as well. We've checked pinouts, clocks, signals; all look fine. We've tried using the ByteBlasterMV with both 3.3V and 5V, no difference. We've buzzed out the cables, tried terminating TCK, and nothing works. But, every now and then, you can press "Program" 55 times and get it to work on the 55th. Sometimes, you can program all 5 chips in a chain a few times without complaint, then it starts failing again. Anybody seen this kind of thing? Any ideas? We're pulling our hair out. Thanks for any suggestions. -- Andrew Reddig andyr@tekmicro.com TEK Microsystems, Incorporated 781.270.0808 One North Avenue Fax 781.270.0813 Burlington, MA 01803 Web http://www.tekmicro.comArticle: 19259
On Wed, 8 Dec 1999 23:49:34 +0100, "OC team" <administration@opencores.org> wrote: >SynaptiCAD supports OPENCORES Initiative with Free HDL Simulators and Test >Bench Generators. Press release is available online at > >http://www.opencores.org/press/press_release_9dec1999.shtml > >regards, > >OPENCORES.ORG team Perhaps Dan Notestein, President of SynaptiCAD, should have told it like it is. In case he needs some help, I've given him some clues below. Dan thinks: "Anyone who's desperate enough to get free IP off the web is going to have to do a *hell* of a lot of verification. So much verification, in fact, that they might as well just have written the code in the first place. However, since we write Verification Tools, this is a Massive Market Opportunity for us. Hey, why don't we ship free tools to developers? Just imagine the phone calls to Opencores 'support': a) 'This core doesn't work'. b) 'Well, I don't know who wrote it, but they used SynaptiCAD, so it must work'. a) 'I just told you it doesn't work'. b) 'I think you're wrong. Hey, why don't you buy SynaptiCAD to check it out?'. "But, on the other hand, this move might piss off Engineers who actually have to work for a living. They might even get so annoyed that they don't buy our tools. They might even point out to other engineers that waveform-based verification is next to useless. But hey, what the hell? It's worth a go."Article: 19260
Utku Ozcan wrote: > <snip> > To overcome this problem, we have inserted FF's between clock domains, > for a possibility of metastability etc. Signals between clock domains > are constrained with acceptable TIMESPEC commands. But no advance. > > I have read several mails posted to newsgroup so far, the opinions > are centered to: > > - incapability of resetting to complete system > - metastability condition right after reset deassertion There is also an effect, often mis-stated as metastability, that is really an aperture time effect. This occurs when you have MULTIPLE registers able to change, on a single clock edge. Or, put another way, if the ASYNC term appears in more than ONE SYNC register equation at a time. If this happens, and you expect 00 -> 11, then you CAN get both 01 and 10 as illegal states, purely as a result of jitter in the Tsu/Th of the two FFs. This can be >> metastability time, and can be hundreds of pS. Eliminating it can be tricky, and normally costs some latency. Jim G. -- ======= Manufacturers of Design Tools for uC and PLD ===== * IceP2051 - Full Speed ICE, for 1K,2K,4K 20 Pin FLASH controllers * OptoISP - Safe, fast In System Program of 89S, 90S, 17C devices => http://www.DesignTools.co.nz/winner51.htm for highlightsArticle: 19261
Hi, I think you have to provide that inputs of the state machines (SM) never change at the time of clock transitions. If it is happens the SM can work incorrectly (for example go to " if others" state ). You could for ex. latch the inputs with other clock transition as SM work Hope it helps, Bonio * Sent from RemarQ http://www.remarq.com The Internet's Discussion Network * The fastest and easiest way to search and participate in Usenet - Free!Article: 19262
I have similar problems with a 7256 and a 10k30, except that the 7256 programs pretty good and the 10k30 is extremely flaky. The funny thing is both are on the same chain. Andrew Reddig wrote: > > Subject tells the story. We have started to have a lot of problems > lately programming Altera devices through JTAG. We have both a > "BitBlaster" (serial interface to JTAG port) and a ByteBlasterMV > (parallel port interface to JTAG). We have had a wide range of problems > on many different designs. > > The common thread is that the device fails to program and MAX-Plus > either reports that the device is unknown, not installed, JTAG chain is > bad, or else does an examine/program and then fails with verify errors. > In the latter case, we can often get exactly the same # of verify errors > each time. > > This happens with two different computers, a couple of different > versions of MAX-Plus, and both the BitBlaster and the ByteBlasterMV. It > also happens with both single EPLD systems and cards that have five > devices in a chain. > > The only common thread is that the problem seemed to start when we > started using MAX7000A's, although it sometimes happens with 7000S > devices as well. > > We've checked pinouts, clocks, signals; all look fine. We've tried > using the ByteBlasterMV with both 3.3V and 5V, no difference. We've > buzzed out the cables, tried terminating TCK, and nothing works. But, > every now and then, you can press "Program" 55 times and get it to work > on the 55th. Sometimes, you can program all 5 chips in a chain a few > times without complaint, then it starts failing again. > > Anybody seen this kind of thing? Any ideas? We're pulling our hair > out. > > Thanks for any suggestions. > > -- > Andrew Reddig andyr@tekmicro.com > TEK Microsystems, Incorporated 781.270.0808 > One North Avenue Fax 781.270.0813 > Burlington, MA 01803 Web http://www.tekmicro.comArticle: 19263
Hi everyone, I am looking for a way to constrain things like pin locations in syntesis for Xilinx with FPGA express. I know it is possible to do this with the "constraint editor", but I'd like to do it by passing attributes from my VHDL source code. I tried tings like: .. port( data: std_logic_vector(7 downto 0); ... attribute LOC: string; attribute LOC of data: signal is "P39,P37,P10,P11,P12,P13,P14,P15"; But these directives are not written in the .xnf netlis, nor in the .ucf file I looked for instructions in the documentation....but I found nothing... Can anybody help me ?? Thanks -- Matthieu Liger, Groupe ESIEE-Paris Currently looking for an internship in microelectronics, see http://www.esiee.fr/~ligermArticle: 19264
Joseph H Allen wrote: > A simple standard we should try to agree on is a two-stage FPGA > configuration process. For stage one we upload a tentative configuration > which keeps all outputs tri-state except for a few which communicate with a > tiny serial flash prom which contains a copy of the card id. Once the card > is verified, stage two is commenced: the FPGA is reconfigured with the > application. When a driver is looking for its cards, it is permitted to > reconfigure cards which are in stage one. Perhaps a good place for this > prom is the M1, M2 and M3 lines which can double-up as I/O (at least for > Xilinx FPGAs). This is only good if everyone uses the same FPGA. Different devices have different configuration bit streams, even if the pin outs are the same. A better solution would be to use a separate, perhaps JTAG compliant, ID rom that could be read before the FPGA was configured. -- -Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email randraka@ids.net http://users.ids.net/~randrakaArticle: 19265
On Mon, 06 Dec 1999 08:33:58 GMT, Leon Heller <leon_heller@hotmail.com> wrote: >Get the Xilinx starter kit. It comes with a JTAG programmer, a little >CPLD evaluation board, and software that supports the CPLDs and the >Spartan series of FPGAs, as well as the older devices. It's about $100. Is that the same one as: http://www.microcall.memec.com/xilinx/promo.htm - £60 in the UK? I'm considering it as an FPGA starter kit- anyone had any experience with it? Any time or feature limitations I should be aware of? I know it doesn't have VHDL./Verilog. If that isn't it, do you have a UK source for the Xilinx one you mentioned? NigelArticle: 19266
I think you'll need to instantiate primitives for the IOBs and put the
attributes on the instance labels, as shown in the snippet below. Also,
FPGA express previously did not pass user attributes to the netlist (about
this time last year). I understand the newer release does, but I haven't
tried it again.
entity foo is
port(
pad
);
end foo;
architecture pad_inst of foo is
component IOBUF
port(
O : out STD_ULOGIC;
IO : inout STD_ULOGIC;
I : in STD_ULOGIC;
T : in STD_ULOGIC);
end component;
attribute LOC: string;
attribute LOC of U1 : label is "P39";
begin
U1:IOBUF port map(
O=> int_out,
IO=> pad,
I=> int in,
T => int_ts);
end pad_inst
Matthieu Liger wrote:
> Hi everyone,
>
> I am looking for a way to constrain things like pin locations in
> syntesis for Xilinx
> with FPGA express. I know it is possible to do this with the "constraint
> editor", but
> I'd like to do it by passing attributes from my VHDL source code.
>
> I tried tings like:
> ..
> port(
> data: std_logic_vector(7 downto 0);
> ...
>
> attribute LOC: string;
> attribute LOC of data: signal is "P39,P37,P10,P11,P12,P13,P14,P15";
>
> But these directives are not written in the .xnf netlis, nor in the .ucf
> file
>
> I looked for instructions in the documentation....but I found nothing...
>
> Can anybody help me ??
> Thanks
>
> --
> Matthieu Liger, Groupe ESIEE-Paris
> Currently looking for an internship
> in microelectronics, see
> http://www.esiee.fr/~ligerm
--
-Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email randraka@ids.net
http://users.ids.net/~randraka
Article: 19267I've just managed to cook a MACH4 ISP chip, I think. As a result of the cooking process, the JTAG ID it returns is all-1's. Has anyone else seen this from cooking MACH4 chips? Or am I likely to have cooked the parallel port programming adapter? cheers,Rich. -- Rich Walker: rw@shadow.org.uk (Shadow Robot Project) http://www.shadow.org.uk 251 Liverpool Road +44(0)171 700 2487 London N1 1LX "Sometimes after an electrical storm I see in 5 dimensions" -- Cornfed Pig, Duckman.Article: 19268
In article <384FBDBE.670FB420@ids.net>, Ray Andraka <randraka@ids.net> wrote:
>Joseph H Allen wrote:
>> A simple standard we should try to agree on is a two-stage FPGA
>> configuration process. For stage one we upload a tentative configuration
>> which keeps all outputs tri-state except for a few which communicate with a
>> tiny serial flash prom which contains a copy of the card id. Once the card
>> is verified, stage two is commenced: the FPGA is reconfigured with the
>> application. When a driver is looking for its cards, it is permitted to
>> reconfigure cards which are in stage one. Perhaps a good place for this
>> prom is the M1, M2 and M3 lines which can double-up as I/O (at least for
>> Xilinx FPGAs).
>This is only good if everyone uses the same FPGA. Different devices have
>different configuration bit streams, even if the pin outs are the same.
It would be fine. If you upload an incorrect bit-stream the fpga ignores it
and you won't be able to read the prom. The driver would then just move on
to the next board. The board's own device driver has to configure it- not
the BIOS.
--
/* jhallen@world.std.com (192.74.137.5) */ /* Joseph H. Allen */
int a[1817];main(z,p,q,r){for(p=80;q+p-80;p-=2*a[p])for(z=9;z--;)q=3&(r=time(0)
+r*57)/7,q=q?q-1?q-2?1-p%79?-1:0:p%79-77?1:0:p<1659?79:0:p>158?-79:0,q?!a[p+q*2
]?a[p+=a[p+=q]=q]=q:0:0;for(;q++-1817;)printf(q%79?"%c":"%c\n"," #"[!a[q-1]]);}
Article: 19269Can someone dirrect me to a specific ap note on how to connect a configuration prom to a Spartan XCS05XL series FPGA. I would prefer to avoid OTP devices. So far I have found information on the XC17S05. This is, of course, a OTP device. I have only one FPGA and one EEPROM. Based on that info I think that this is correct: FPGA (XCS05XL) PROM DIN <----- DATA CCLK -----> CLK DONE -----> CE (Is this direction correct?) INIT_bar -----> OE/reset_bar my guess for the other signals FPGA INPUTS OTHER SIGNALS M0 ----- open circuit(??) M1 ----- open circuit(??) PWR_DOWN_bar ----- held low until power is stable The data sheet on the Spartan configuration prom shows a reset input on the FPGA but I can't find that in the data sheet (except for the one generated in my design) so I assume that that is really the PWR_DOWN_bar signal. In my case the power could come up comparitively slowly. (I am note certain how long, but 50 mSec is only 3 full cycles at 60 Hz.) I note that the ap notes talk about power supply rise time (1 to 3 volts) being less than 50 mSec. Is there a _simple_ hardware work around for this problem such as holding some pin(s) low? I would rather not switch the FPGA power supply. Obviously the In-Circuit-Programable device would use some more signals on the configuration PROM. What are they and how do I connect them? Again specific examples would be greatly appreciated. I would rather get this correct the first time. While I am at it what ISP device is appropriate for the XCS05XL Spartan FPGA? As a second alternative a reprogramable but not ISP device would be a second choice. Thanks so much for your patience and help.Article: 19270
This is original message from the CAN LIST -- CANLIST message -- The European Space Agency has released the VHDL source code of the prototype CAN controller core. Information can be found at the following address: ftp://ftp.estec.esa.nl/pub/ws/wsd/CAN/can.htm The core is now in its Alpha 3.0 version, that means non extensively tested and not passed the official Bosch testbench. Please note that the simulation libraries for Modeltech and the pre-synthetized version for ACTEL FPGA are free, while to been able to extract the VHDL source files you need a password. If you want to join the development effort and receive the password to extract the source files please print the Non Disclosure Agreement that you find on the web page and send it signed to the indicated address. F. Mazzaglia ESA/ESTEC Keeplerlaan 1 2200 AG, Noordwijk The Netherlands The NDA is meant to limit the distribution of the source code before it become an official release. The usage of the core is not restricted in any way by ESA, and the core will remain always of public domain. Please note that to produce a CAN node chip you have to request a license to Bosch for copyright fee. Luca Stagnaro (lstagnar@estec.esa.nl) Spacecraft Control and Data Systems Division Automation and Informatics Department European Space Agency -- To unsubscribe use canlist-request@vector-informatik.de Archive: ftp://ftp.vector-informatik.de/pub/archive/ Problems to canlist-owner@vector-informatik.de Home at Vector Informatik GmbH, Germany (www.vector-informatik.de) -- CANLIST message -- Hope it helps. I can not tested the model yet Joseph Hlebasko wrote: > I don't have the URL with me, but on the CAN mailing list a notice was > published about a "public domain" CAN core. The organization was > European Space Agency (ESA). The project name was "HuriCANe" > and was implemented with the purpose of studying the CAN controller. > I think if you do a search for ESA & Huricane you may find it. > > Joseph Hlebasko > > Jonathan Bromley <jonathan@oxfordbromley.u-net.com> wrote in message > news:3846DC36.F45F08DA@oxfordbromley.u-net.com... > > "Raymond E. Rogers" wrote: > > > > > I am organizing a CAN-2.0B testing procedure. > > <snip my suggestion> > > > This is certainly feasable and has some advantages > > <snip> > > > OTOH, it > > > is not as general and synchronization with the MAC layer would have to > > > be resolved. > > > > Yes indeed. - hence my comment about fooling the Rx. > > > > It occurs to me to ask whether anyone out there has a > > synthesisable VHDL core for a CAN controller. It clearly > > wouldn't be cost competitive with commodity CAN parts > > for production, but it sure as hell would make this kind > > of diagnostic and special-purpose stuff far easier if you > > had a working controller core to start from that you could > > modify in an arbitrary way. > > > > I would be **very** interested in getting involved in > > any public-domain effort to realise this goal, as I > > have upcoming projects for which it would be rather > > useful. > > > > I've posted this also to comp.arch.fpga and comp.lang.vhdl > > (from sci.electronics.design) in the hope of exciting some > > interest. > > > > Jonathan BromleyArticle: 19271
Hi again, It sounds daunting but it is not hard. You only need a bi-directional counter for the read pointer, and you design the full/empty logic to make the FIFO appear a little "smaller" than you normally would. For example, if you used SelectRAM in any Xilinx device, you could create a 14-deep FIFO with a 2-entry back up buffer (so to speak) by designing the flags as if it were really a 14-deep FIFO. You would never corrupt the data in the FIFO, even if you have to back up. Obviously, you can build larger FIFOs if you require using additional SelectRAM, or if you need a really big FIFO, you can use a Virtex device and use the BlockRAM. As you said, there are simpler alternatives depending on what you are trying to do. We are trying to support the broadest range of applications with our product, and have to account for cases where customers cannot flush their FIFO. Thanks, Eric Crabill Bruce Nepple wrote: > A backup fifo gets a little messy when you start dealing with full/empty > issues. Little side effects that make things messy. > > Actually, all you really need to do is to start another transaction on that > channel to flush the holding register. > That would be simpler than (in my case) 3 updown counters and messy logic.Article: 19272
Hi
This is a question from a recent Synopsys user. I did a small design
to XC6200 using structural VHDL. I have the VITAL compatible library with
XC6200 primitives (AND, OR, and so on).
I analyzed this design for simulation. The high level (behavioral)
simulation works well. But I can't backannotate the design with the timing
parameters generated by the placer/router tool, for accurate gate-level
simulation. These parameters are in SDF format, and looking into the file,
it makes sense. Look:
(CELL
(CELLTYPE "AND2B1")
(INSTANCE COUNT_COL/COUNT_0_INI_1_C_MUX)
(DELAY
(ABSOLUTE
(PORT I0 (9.476:9.476:9.476) (8.143:8.143:8.143))
(IOPATH I0 O (0:0:0) (0:0:0))
(PORT I1 (3.040:3.040:3.040) (3.575:3.575:3.575))
(IOPATH I1 O (0:0:0) (0:0:0))
...
When I read the design the messages are:
# vhdlsim -fi_all -sdf_typ -sdf_top /tb_addr/c_addr -sdf addr.sdf CFG_TB_ADDR
**Error: vhdlsim,259:
(SDF File: addr.sdf Line: 20) instance
/TB_ADDR/C_ADDR/COUNT_COL/COUNT_0_INI_1_C_MUX not found.
... and a lot of messages about other instances
Looking into the design tree, using vhdlsim, I found the path to the
cell shown above.
# pwd
/TB_ADDR/C_ADDR/COUNT_COL/COUNT(0)/INI/C_MUX
# ls
TIMINGCHECKSON MSGON TIPD_I1 I1
VITALBEHAVIOR
INSTANCEPATH TPD_I0_O TIPD_I0 I0 I1_IPD
XON TPD_I1_O O WIREDELAY I0_IPD
I suppose there is a problem naming the instances. My placer/router
is the XACT6000 and there is no option to control the generation of instance
names in SDF file. Is there some config in Synopsys analyzer to make the
names of instances compatible with the names of SDF? Or this problem needs
another solution ?
Sorry for the long posting. But it is very, very important! Thanks in
advance.
--
| Walter Soto Encinas Jr |
| PhD Student |
| IFSC / USP |
| Brazil |
Article: 19273Walter Soto Encinas Junior wrote in message <385023E4.722A4379@icmc.sc.usp.br>... >Hi > > This is a question from a recent Synopsys user. I did a small design >to XC6200 using structural VHDL. I have the VITAL compatible library with >XC6200 primitives (AND, OR, and so on). > > I analyzed this design for simulation. The high level (behavioral) >simulation works well. But I can't backannotate the design with the timing >parameters generated by the placer/router tool, for accurate gate-level >simulation. These parameters are in SDF format, and looking into the file, >it makes sense. Look: > ># vhdlsim -fi_all -sdf_typ -sdf_top /tb_addr/c_addr -sdf addr.sdf CFG_TB_ADDR > >**Error: vhdlsim,259: > (SDF File: addr.sdf Line: 20) instance > /TB_ADDR/C_ADDR/COUNT_COL/COUNT_0_INI_1_C_MUX not found. > >... and a lot of messages about other instances > > Looking into the design tree, using vhdlsim, I found the path to the >cell shown above. > ># pwd >/TB_ADDR/C_ADDR/COUNT_COL/COUNT(0)/INI/C_MUX ># ls >TIMINGCHECKSON MSGON TIPD_I1 I1 >VITALBEHAVIOR >INSTANCEPATH TPD_I0_O TIPD_I0 I0 I1_IPD >XON TPD_I1_O O WIREDELAY I0_IPD > > I suppose there is a problem naming the instances. My placer/router >is the XACT6000 and there is no option to control the generation of instance >names in SDF file. Is there some config in Synopsys analyzer to make the >names of instances compatible with the names of SDF? Or this problem needs >another solution ? Have you compiled the Xilinx simulation libraries? -- a ----------------------------------------- Andy Peters Sr Electrical Engineer National Optical Astronomy Observatories 950 N Cherry Ave Tucson, AZ 85719 apeters (at) noao \dot\ edu The secret of Slurm is on a need-to-know basis.Article: 19274
BZZZZT. Wrong, not if you want an independent read address. If you use a single ported RAM for the second, it's read address is the same as the common write address, which you already have on the first instance. John L. Smith wrote: > Jan Gray wrote: > > > [ stuff about multiport SRAMS in FPGAs, concentrating on 3-port RRW ] > > > > * 2 2-port SRAMs and do the two RR accessses and the W access in one cycle. > > A 25% more area efficient implementation would use 1 2-port and 1 > 1-port. > > - John > > ------------------------------------------------------------------------ > > John L. Smith <jsmith@visicom.com> > Principal Engineer > Visicom Imaging Products > > John L. Smith > Principal Engineer <jsmith@visicom.com> > Visicom Imaging Products HTML Mail > 10052 Mesa Ridge Court Work: 858-320-4102 > San Diego Fax: 858-?????? > CA Netscape Conference Address > 92121 Netscape Conference DLS Server > USA > http://www.visicom.com/products/Vigra/index.html > Additional Information: > Last Name Smith > First Name John L. > Version 2.1 -- -Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email randraka@ids.net http://users.ids.net/~randraka
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