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
vax, 9000 wrote:
> Hi group,
> Sorry to bother you again. I am developing code for a hobby project and I
> need to simulate my design with some off-chip-connected-pins. For example,
> I generate a secondary clock on chip, output it from a pin, and feed it
> into another pin (dedicated clock pin). How do I simulate it? Where do I
> tell the simulator that the two pins are connected? I guess one possible
> place is the test bench vhdl source file, and another possible place is the
> simulator command lines where I 'force' the input pins...
Err, force? Are you using a force file? Please don't do that. Write a
proper VHDL testbench; google around for some examples. For the example
you mention above, the code is trivial:
architecture board of bd_top is
constant CLK_PRD : Time := 10 nS;
signal CLK;
signal CLK_FB;
begin
UUT: entity work.my_device
port map (
CLK => CLK,
FBCLK_OUT => CLK_FB,
FBCLK_IN => CLK_FB
);
-- Generate the clock.
clk_gen: process
begin
loop
Clk <= '1' after CLK_PRD/2, '0' after CLK_PRD;
wait for CLK_PRD;
end loop;
end process clk_gen ;
end architecture board;
--
My real email is akamail.com@dclark (or something like that).
Article: 75701The Xilinx core generator generates std_logic_vector(0 downto 0) on some parts like a BUSMUX. How do you "cast" this IO so that it can be connected to std_logic without errors? Brad Smallridge b r a d @ a i v i s i o n . c o mArticle: 75702
On Fri, 12 Nov 2004 05:11:23 -0800, "Lars Theodorsson" <lars.theodorsson@se.flextronics.com> wrote: >Is there a way to list the unconstrained paths? > >The timing report with trace -u only lists the number >of unconstrained paths and the maximum delay. I would >like to see them to assert that I have not missed a >vital path in my constraints. The timing analyzer has no way of knowing which paths are vital to you. Use -u followed by a number, e.g., -u 100, and you'll get a report of that many unconstrained paths, sorted from longest to shortest. Bob Perlman Cambrian Design WorksArticle: 75703
Brad, if a : std_logic_vector(0 downto 0) ; and b : std_logic ; then b <= a(0) ; Hope this help, Andrea "Brad Smallridge" <bradsmallridge@dslextreme.com> wrote in message news:10p9p836ut3ila4@corp.supernews.com... > The Xilinx core generator generates std_logic_vector(0 downto 0) on some > parts like a BUSMUX. How do you "cast" this IO so that it can be connected > to std_logic without errors? > > Brad Smallridge > b r a d @ a i v i s i o n . c o m > > >Article: 75704
"Brad Smallridge" <bradsmallridge@dslextreme.com> wrote in message news:10p9p836ut3ila4@corp.supernews.com... > The Xilinx core generator generates std_logic_vector(0 downto 0) on some > parts like a BUSMUX. How do you "cast" this IO so that it can be connected > to std_logic without errors? > > Brad Smallridge > b r a d @ a i v i s i o n . c o m signal_not_vector <= signal_vector_size0(0); maybe there is other way, but I do the above if needed. AnttiArticle: 75705
Jim Granville <no.spam@designtools.co.nz> wrote in message > > There is an opening for more portable assemblers, call it a "Structured > Assembler", or a C-Syntax Assembler, if you will. > These will always be subsets, but if they implement a common > preprocessor, and in-line asm, for example, then it will be possible to > have one source file that is portable. > Eg A design could start on a PC, to develop the algorithm, and then > be re-coded/optimised as needed, to target tiny cores, like the > PicoBlaze, et al. Isn't that why they make software simulators? Though I can see the need for portability when you don't yet know how much work the application will involve to select a suitable processor. ChrisArticle: 75706
"Arash Salarian" <arash.salarian@epfl.ch> wrote in message news:419496dd$1@epflnews.epfl.ch... > > The critical parameter for you is deltaV / deltaT for the hold state. > Typically, this value is round one milivolts per second for a good quality > 1u capacitor! So for 5 minutes that would be round 0.3 volts. Maybe you > can find a better part than LF198 but the big problem is to find a very > high quality capacitor that it's internal impedance is actually much > higher than the input impedance of the sample and hold IC. > The advantage of using ICs like that is their tiny size and small board > area (you just need one small IC and one capacitor). > But she doesn't need to hold for 5 minutes. The DAC can be updated at a 1 MHz rate. If she has 10 outputs, she can refresh each output every ten microseconds. As long as the DAC and t/h have no serious glitch this has no downside, and allows the use of small caps without droop.Article: 75707
As part of an academic project I'm going to be looking at the pros and cons of re-producing microprocessors in current FPGA technologies that are no longer available on the open market. This is to address the problem that occurs in some specialised areas where the lifetime of a product is very long and the cost of rewriting the software is prohibitively high (e.g. it was written in a language and/or tools that aren't supported anymore). The idea is to be able to use an FPGA implementation an either a drop-in replacement component onto a legacy board or to produce a new board but of identical functionality. Either way, no changes to the application object code stored in ROM is required. There are many different factors that I'll have to look into before I can make any conclusions and I'm concerned that some important ones could be missed. Obviously there are: 1) Availability of the original processor HDL or equivalent. 2) How can the exact EBI timings of the original be recreated (or how close to the original is practical)? 3) Cache memory cannot be recreated on-chip. 4) How close can the internal timings be recreated? 5) Verification ?! If anyone would like to contribute to this initial brainstorming, I'd be grateful. Rupert.Article: 75708
Has anyone here worked on or have run across a hobbyist-scale project using DVI video/graphics? I would like to experiment with a DVI transmitter fed by a dedicated SDRAM framebuffer, but I do not know where to start. My experience is with PIC- and SX-based projects, but I'm about to start working with FPGA projects. Any advice is appreciated!Article: 75709
On Fri, 12 Nov 2004 17:28:56 +0000, Ryan wrote: > As part of an academic project I'm going to be looking at the pros and cons > of re-producing microprocessors in current FPGA technologies that are no > longer available on the open market. This is to address the problem that > occurs in some specialised areas where the lifetime of a product is very > long and the cost of rewriting the software is prohibitively high (e.g. it > was written in a language and/or tools that aren't supported anymore). The > idea is to be able to use an FPGA implementation an either a drop-in > replacement component onto a legacy board or to produce a new board but of > identical functionality. Either way, no changes to the application object > code stored in ROM is required. > > There are many different factors that I'll have to look into before I can > make any conclusions and I'm concerned that some important ones could be > missed. Obviously there are: > 1) Availability of the original processor HDL or equivalent. Systems that were designed 20 years ago were designed with paper schematics not HDLs. If the manufacturer still exists, and most of them are long gone, the designs are going to be hidden away in a long forgotten file cabinet. The architecture manuals may be still be available some where, maybe even on the net. I've seen sites devoted to the Data General machines for example (I was one of the designers of the DG MV8000 in the late 70s which is why I've looked). The good news is that machines of that vintage were relatively simple because of the limited number of gates that we had available. The smallest FPGA has more gates that any minicomputer of the 70s and the available block RAM in a decent size FPGA exceeds the main memory sizes of many of those machines. The caches, if any, were tiny. A couple of block RAMs is enough. Also modern HDLs like Verilog vastly simplify the design task. One person using Verilog and a decent simulator can do in a few weeks what it took a team of people a couple of years to do in the 70s and early 80s. > 2) How can the exact EBI timings of the original be recreated (or how > close to the original is practical)? This probably isn't practical. > 3) Cache memory cannot be recreated on-chip. Easily done on chip 4) How close can the > internal timings be recreated? It would be hard to reporduce it exactly, but why would you want to? Minicomputers of the 70s had clock speeds of 5-10MHz, modern FPGAs run at over 100MHz without any work at all, and much faster if you put even modest effort into it. 5) Verification ?! If you can find the orginal diagnostics that would give you a start. In the 70s machines and early 80s machines were debugged in the lab using instruction set diagnostics. The prototype machines were built on wirewrap boards which could be fixed almost as easily as we change a line of Verilog today. The simulators that existed weren't very good and the machines that they ran on were too slow to do any serious debugging so there was no such thing as a testbench as we know it today. The real debugging was in hte lab. > > If anyone would like to contribute to this initial brainstorming, I'd be > grateful. > > Rupert. While it is practical to emulate an obsolete architecture in an FPGA it's not clear that it's the right thing to do. Using a software emulator is the more cost effective way to do this. Moores law works out to a factor of 100 per decade which means that in the last 25 years the performance/price ratio has improved by a factor of 100,000. Today's desktop PC is several thousand times faster than the super minicomputers of the late 70s while being a factor of 100 cheaper. What this means is that even if took you 100 instructions to emulate a single instruction on an antique machine the emulator would still run 20-30 times faster than the original machine did. Of course a decent emulator should be able to do a lot better than this but my point is that even the crudest software emulator could do the job.Article: 75710
It might be an intriguing exercise, but
but don't expect much outside interest in the
results. Those parts are obsolete for good reasons.
-- Mike Treseler
Article: 75711mrand@my-deja.com (Marc Randolph) wrote in message news:<15881dde.0411101917.47c12fef@posting.google.com>... > herwin@ee.ucla.edu (Herwin) wrote in message news:<6314bb40.0411101033.43e00fd4@posting.google.com>... > [...] > > Here is the situation. Using a 50Mhz oscillator I am trying to > > achieve a channel bit rate of 1Gbps in 8/10 bypass mode. For every 20 > > bits, I am transmitting 5 'ones' in random positions. This should > > ensure that I have at least 1 transition every 20 bits and enough for > > the PLL to lock on to the clock. What I am seeing is that the bit > > error rate is very high (>0.1). This is the case even when I set the > > MGT to serial bypass mode. What can be the cause of this since this > > configuration introduces no transmission losses? > > Howdy Herwin, > > I'm not sure what serial bypass mode is - did you mean 8b/10b bypass? The system runs with 8/10 bypass, and the tests that I performed used the serial loopback mode. Parallel loopback works perfectly. The clock that I am using is directly from a crystal oscillator from Sunstu (SOVB25T). Indeed, I am now suspecting that the jitter requirement has been violated. I am now trying to investigate what this jitter is on this part. As for how the reference clock is routed: The signal is first fed through an input buffer. The output net is connect to both a DCM (for the logic) and the MGT reference clock input. Thanks a lot for the feed back HerwinArticle: 75712
Ryan wrote: > As part of an academic project I'm going to be looking at the pros and cons > of re-producing microprocessors in current FPGA technologies that are no > longer available on the open market. This is to address the problem that > occurs in some specialised areas where the lifetime of a product is very > long and the cost of rewriting the software is prohibitively high (e.g. it > was written in a language and/or tools that aren't supported anymore). The > idea is to be able to use an FPGA implementation an either a drop-in > replacement component onto a legacy board or to produce a new board but of > identical functionality. Either way, no changes to the application object > code stored in ROM is required. > > There are many different factors that I'll have to look into before I can > make any conclusions and I'm concerned that some important ones could be > missed. Obviously there are: > 1) Availability of the original processor HDL or equivalent. > 2) How can the exact EBI timings of the original be recreated (or how close > to the original is practical)? > 3) Cache memory cannot be recreated on-chip. > 4) How close can the internal timings be recreated? > 5) Verification ?! > > If anyone would like to contribute to this initial brainstorming, I'd be > grateful. A good place to start, is to look at what is already out there. This is a good launch site http://www.lug-kiel.de/links/details/hdl.html Look at devices like 6502, 6809, & 8080 as simpler examples of cores that have a wider code base, but are not active hardware any more. Peripheral logic is likely to be as much/more work than the core. There is also a lot of work being done on game-machine emulation. Someone has mentioned SW emulation, for an interesting take on that see http://www.xilinx.com/publications/xcellonline/xcell_48/xc_picoblaze48.htm [this uses a Soft CPU in a FPGA to SW Emulate a more complex CPU ! ] Where you have spare speed, this approach can save resource. What would be interesting research, would be a tool chain that allowed a soft-boundary and generic approach to the replacement of any core. The most flexible emulation, would be to start using a tinycore, and calling Target Opcode Sw emulation blocks. This gets the system working, but at a lower speed. Then, you analyse the blocks, and target the frequent/slow ones, to be replaced by either FPGA Logic resource, or opcode extension on the original core. -jgArticle: 75713
>Someone has mentioned SW emulation, for an interesting take on that >see >http://www.xilinx.com/publications/xcellonline/xcell_48/xc_picoblaze48.htm > >[this uses a Soft CPU in a FPGA to SW Emulate a more complex CPU ! ] There was a time when it was common to implement instruction sets by writing microcode that ran on real hardware. The general idea on the ones I'm familiar with was to use a wide instruction word that was easy to decode and simple to implement. (and ran very fast) It might be fun to do that in an FPGA. I wonder how much it takes to implement a 6502 or such. -- The suespammers.org mail server is located in California. So are all my other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited commercial e-mail to my suespammers.org address or any of my other addresses. These are my opinions, not necessarily my employer's. I hate spam.Article: 75714
It's clear that the "mux" is really an integral part of the
DDR flop design. It has been suggested that the individual
flip-flops are not really wired as shown, but rather wired so that
the outputs can be XORed together to form the final Q output.
This method does not have a glitch if the Q doesn't switch.
See VHDL code below.
The only reason I can see to use 180 DCM output (which uses extra
global routing resources) is if the clock you're using is not
50% duty cycle. Normally DCM outputs are adjusted to 50% unless
you tell the tools specifically not to. Thus using 0 phase clock
and its inverse (yes the inverter is pulled into the IOB) gives
just as good results. I think newer reference designs use this
method instead of the 0 and 180 method.
I have used DDR flops as clock drivers because they make a good
low skew (but not zero delay) copy of a global clock signal without
extra routing resources related to using multiple DCM phases or
2x clocks. They also neatly match the data delay in DDR SDRAM
designs.
newman5382@aol.com (Newman5382) wrote in message news:<20041112103601.06264.00000418@mb-m18.aol.com>...
> Just as a follow-up: The original question is a good one. When one sees a 2:1
> mux, one may wonder if it is susceptable to static hazard one and static hazard
> zero glitches. I've seen that Xilinx recommends using this component for clock
> forwarding, which implies that it is not subject to such. When I reviewed the
> design in the FPGA editor, the inverter in the C1 path was apparently absorbed
> into the IOB. In some App note for high speed designs, it was recommended that
> the 180 DCM output be used for C1. Since my design was not high speed, and I
> was running out of clock buffers on that side of the chip, I opted for the
> merged inverter. Apparently the "DDR Mux" uses two clocks, and it is unclear
> exactly how it does that.
>
> - Newman
>From anonymous source:
There was a post a while back on comp.lang.vhdl about double edged
clock circuits, and one of the responses included code for a double
edged register built from two single edged registers and three XOR
gates.
Basically, the way it worked was that the state of the DDR register
was encoded as follows: Whenever the states of the two individial
registers was different, the output was a '1', whenever they were the
same, it was a zero. The following code will synthesize in
synplify-pro, but might have to be split into separate processes for
other tools. It creates a multiple-"bit" DDR "register", using SDR
registers, with parameterizable size and reset value, through vhdl
generics (it cannot puch this into an IOB's DDR register)
I don't know if this is the circuit that Xilinx uses or not (note that
if one flop is held in reset, the circuit reverts to single edge
functionality), but the output "mux" is really just an XOR gate, and
no clocks are needed!
library ieee;
use ieee.std_logic_1164.all;
entity ddrff is
generic (size : positive := 1;
rstval : std_logic_vector := (0 => '0') --
unconstrained, defaults to 1 bit
);
port (d : in std_logic_vector(size - 1 downto 0);
q : out std_logic_vector(size - 1 downto 0);
clk : in std_logic;
rst : in boolean
);
end ddrff;
architecture rtl of ddrff is
signal qr, qf : std_logic_vector(d'range);
begin
-- Double Data Rate Flip Flop Circuit
-- two bit state is encoded as follows:
-- if flops differ, the 'value' is '1'
-- if flops match, the 'value' is '0';
-- therefore either flop (on either edge) can change the state or
-- keep it the same, and a simple xor gate decodes the state to
-- produce the output
-- output is glitch free
main:
process (rst,clk) is
begin
if rst then
qr <= (others => '0');
qf <= rstval;
elsif rising_edge(clk) then
qr <= qf xor d;
elsif falling_edge(clk) then
qf <= qr xor d;
end if;
end process;
-- decode output
q <= qr xor qf;
end rtl;
Article: 75715>It's clear that the "mux" is really an integral part of the >DDR flop design. It has been suggested that the individual >flip-flops are not really wired as shown, but rather wired so that >the outputs can be XORed together to form the final Q output. I started thinking along that line. I couldn't make it work. Consider the case where the FFs are fed by 1/0 constants to make a clock. The value of the FFs never changes. I'm sure the actual implementation has some interesting magic. >The only reason I can see to use 180 DCM output (which uses extra >global routing resources) is if the clock you're using is not >50% duty cycle. ... At least one place in the Xilinx documentation suggests using clk and clk180 in preferance to clk and clk-inverted for better results. I think the idea was that there is more skew on rising vs falling edges as compared to loaded and not-loaded clock distribution nets. Might be fun to measure. I wonder how hard it would be to make something that balanced the clock loading. Probably doable in FPGA editor by hand for a one-shot experiment. >I have used DDR flops as clock drivers because they make a good >low skew (but not zero delay) copy of a global clock signal without >extra routing resources related to using multiple DCM phases or >2x clocks. They also neatly match the data delay in DDR SDRAM >designs. You could use a DLL with external feedback if you want to avoid that delay. But that delay doesn't matter for the normal clock forwarding case. -- The suespammers.org mail server is located in California. So are all my other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited commercial e-mail to my suespammers.org address or any of my other addresses. These are my opinions, not necessarily my employer's. I hate spam.Article: 75716
Ian, Stratix II GX will elevate LE count, increase transceiver speed, and increase channel count. I think the majority of chip-to-chip and backplane requirements in the next generation will be better addressed by transceiver speeds in the 5-6 Gbps range than in the 10-12 Gbps range based on supporting infrastructure required. More details on Stratix II GX are available today with an NDA. Dave Greenfield Altera Marketing > > > > I've been trying to work out what total serial I/O capability is > > available on the latest (and near future!) FPGAs, but it's not always > > easy. In the timescales I'm looking at I guess that the likely > > candidates are Virtex-4 (for which little information is available on > > the MGTs), and whatever the "next-generation" Altera device is > > (Stratix-II doesn't have serial I/O, Stratix GX does but may be > > lacking in processing power) -- can anyone at Altera give any clue > > about this? > > > > > > > > Cheers > > > > Ian Dedic > > Chief Engineer > > Mixed Signal Division > > Fujitsu Microelectronics Europe > > > > P.S. If there are things which can only be revealed under NDA, please > > contact me off-list since we have NDAs with both Xilinx and Altera.Article: 75717
"Veronica Matthews" <ikeepthespiritalive@freenet.de> wrote in message news:<cn1vol$r7k$1@news.cs.tu-berlin.de>... > Just to put my aim in perspective: I'm neither trying to fool you nor trying > to get my homework solved (like a given individual presumed). Why I am > talking about a basic condition with respect to the "one D/A converter for > multiple output channels"-configuration is that this single D/A converter > already exists in hardware. It is there, physical, for me to touch, already > bought... And now I want to use this very D/A converter to feed several > output channels. Of course I could buy a DAC for every channel but that's > not my intention. The hardware setup does not allow to solder other devices > on the board. So PLEASE just take it as it is! I want to solve the problem > that way. So don't try to proselytize me like that jehovah's witnesses > guys... ;-) > > Hope you come up with more constructive suggestions! > > Veronica ok, what you want is a sample-and-hold for each channel and yes that could be a cap a switch and an opamp buffer, the "droop" will depend on the capacitor and what's discharging it (don't forget that cap is self) you say you can't solder anything on the board, but you can fit several opamps high quality switches and caps? what will control the switches? A multiple output DAC give you all of it in a single package, it so much simpler and most likely better... you do sound a little like the jehovas witnesses ;) -LasseArticle: 75718
"Veronica Matthews" <ikeepthespiritalive@freenet.de> wrote in message news:<cn1vol$r7k$1@news.cs.tu-berlin.de>... > Just to put my aim in perspective: I'm neither trying to fool you nor trying > to get my homework solved (like a given individual presumed). Why I am > talking about a basic condition with respect to the "one D/A converter for > multiple output channels"-configuration is that this single D/A converter > already exists in hardware. It is there, physical, for me to touch, already > bought... And now I want to use this very D/A converter to feed several > output channels. Of course I could buy a DAC for every channel but that's > not my intention. The hardware setup does not allow to solder other devices > on the board. Presumably you have space for the analogue sample/hold or demux arrangements? > So PLEASE just take it as it is! I want to solve the problem > that way. So don't try to proselytize me like that jehovah's witnesses > guys... ;-) Well, I won't try to proselytise, but you really need to know that some problems just *can't* be solved "as it is"! Maybe the solution can be found only if you re-frame the problem somewhat... Since you want DC-like output, it seems to me that the best way would be to make a bank of sample/hold circuits, one per output channel, and refresh them as frequently as possible. The digital value corresponding to each channel's output can be held in an internal register or small RAM bank, and the one-and-only DAC can be cycled round all these values continuously. That way, the sample/hold circuits don't need particularly special droop performance and they could probably be built using simple analogue switches and small-value capacitors. It would require just a little extra logic in your FPGA, of course, but it sounds like only half an afternoon's work to me. Alternatively, why not abandon the dedicated DAC altogether, and provide one single FPGA output per analogue channel? These digital outputs can then be pulse-width modulated by logic inside the FPGA, and low-pass filtered on the output side by a simple single-stage RC. Once again, the fact that you are trying to create "DC" outputs comes to your aid: the RC filter can be quite brutal (have a very long time constant), simplifying the PWM design. I know of no straightforward analogue sample/hold that can give you very low droop over a period of minutes. Consequently, your original approach to the problem is unworkable. No proselytising, just good old-fashioned experience! -- Jonathan BromleyArticle: 75719
Is it possible to use the Block RAMs in the Spartan3 with the (free) WebPACK software? If so, how? I'm playing with the Spartan3 starter kit and trying to make a ROM. I'd expect to find something in the library package. I can't find anything there other than tiny ones using CLBs. Looks like the normal path is to use Coregen, but that's not part of WebPACK. I could use a machine with Coregen installed on it to do the "gen" part, but that makes something that's tangled up with the Coregen libraries. (Maybe that tangle is only the simulation libraries. But everybody would snicker if I didn't simulate.) Am I just overlooking something simple? (If so, what's the magic word.) -- The suespammers.org mail server is located in California. So are all my other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited commercial e-mail to my suespammers.org address or any of my other addresses. These are my opinions, not necessarily my employer's. I hate spam.Article: 75720
"Veronica Matthews" <ikeepthespiritalive@freenet.de> wrote in message news:<cn1vol$r7k$1@news.cs.tu-berlin.de>... > Just to put my aim in perspective: I'm neither trying to fool you nor trying > to get my homework solved (like a given individual presumed). Why I am > talking about a basic condition with respect to the "one D/A converter for > multiple output channels"-configuration is that this single D/A converter > already exists in hardware. It is there, physical, for me to touch, already > bought... And now I want to use this very D/A converter to feed several > output channels. Of course I could buy a DAC for every channel but that's > not my intention. The hardware setup does not allow to solder other devices > on the board. So PLEASE just take it as it is! I want to solve the problem > that way. So don't try to proselytize me like that jehovah's witnesses > guys... ;-) How quickly and how often can you cycle through the channels? If you can afford to do it at a high rate to refresh the outputs, the sample/hold requirements may be fairly simple. At the extreme, if you have a fast enough clock and can afford to devote on on-chip counter per chanel, or a fair amount of processor attention to the problem, you can just use pulse width modulation of your chanel selects to produce your outputs, without needing any external "DAC hardware" at all. Or look at doing sigma-delta modulation. Don't rule out the possibility that you may find multichanel outboard DAC's that take up less board space than whatever analog sample/hold solutions you could come up with. ChrisArticle: 75721
"mike_treseler" <tres@fl_ke_networks.com> wrote in message news:b0118205e8cb94b0184ad5644ab2a5f0@localhost.talkaboutelectronicequipment.com... > It might be an intriguing exercise, but > don't expect much outside interest in the > results. Those parts are obsolete for good reasons. True. It only becomes interesting when you have an application that cannot be economically or practically replaced by software re-writes or a desktop PC. I heard that the space shuttle is having a hard time sourcing 8086 chips. These were decent in the late seventies when the shuttle was developed. Many military flight systems suffer from part obsolescence. Concorde used many analogue computers. It was never going to be economic to upgrade those to modern technology and test them all. In all the cases above, it is too dear to re-write code and impractical to stick in a modern PC running an emulator. A Blue Screen of Death might easily become a White Hot Screen of Death. It is interesting to look at space craft over the years. The early space craft looked rather like pinball machine panels. The recent Spaceship One cockpit looked like a it had a single LCD panel and a joystick. In another field, the wartime Colossus is said to be on a par with recent PCs, but internal workings are still quite closely guarded. Partly because the guy looking at it regards it as his project a lot, and doesn't want to give too much away. He is also under the official secrets act, so there's always the risk of having a suspicious suicide in the woods. ;-)Article: 75722
I don't believe you can... The 20k RAM is some what specialized as compared with more modern FPGAs. But why not just use a 16bit shift register on the input? Simon "Manfred Balik" <e8825130@stud4.tuwien.ac.at> wrote in message news:41945fa6$0$11614$3b214f66@tunews.univie.ac.at... > Is it possible to configure a DualPartRAM in an Altera APEX20KE (using > Quartus II 4.1) to > write serial to the RAM (1 Bit) and > read parallel from the RAM (16 Bit)? > > Thanks, Manfred > >Article: 75723
"Hal Murray" <hmurray@suespammers.org> wrote in message news:nNednVl0h_eftgjcRVn-hQ@megapath.net... > >Someone has mentioned SW emulation, for an interesting take on that >>see >>http://www.xilinx.com/publications/xcellonline/xcell_48/xc_picoblaze48.htm >> >>[this uses a Soft CPU in a FPGA to SW Emulate a more complex CPU ! ] > > There was a time when it was common to implement instruction > sets by writing microcode that ran on real hardware. The general > idea on the ones I'm familiar with was to use a wide instruction > word that was easy to decode and simple to implement. (and ran > very fast) > > It might be fun to do that in an FPGA. I wonder how much it takes > to implement a 6502 or such. quite a few 6502 cores available www.opencores.org www.fpgaarcade.com http://home.freeuk.com/fpgaarcade/platforms.htm vic20,6502 http://home.freeuk.com/fpgaarcade/pac_main.htm z80 http://zxgate.sourceforge.net/ zx81 ,zx spectrum, jupiter ace, trs80 http://www.fpga-games.com/ commadore 64 http://c64upgra.de/c-one/ http://www.howell1964.freeserve.co.uk/logic/index_logic.htm lots of stuff see the links AlexArticle: 75724
there is lots missing from the webpack. but you can still use memory in vhdl or verilog by just describing it :-) just infer it. there are a few examples in webpack of this Simon "Hal Murray" <hmurray@suespammers.org> wrote in message news:RuednZqh6-LY5QjcRVn-hQ@megapath.net... > Is it possible to use the Block RAMs in the Spartan3 > with the (free) WebPACK software? If so, how? > > I'm playing with the Spartan3 starter kit and trying to make > a ROM. I'd expect to find something in the library package. > I can't find anything there other than tiny ones using CLBs. > > Looks like the normal path is to use Coregen, but that's not > part of WebPACK. I could use a machine with Coregen installed > on it to do the "gen" part, but that makes something that's > tangled up with the Coregen libraries. (Maybe that tangle is > only the simulation libraries. But everybody would snicker if > I didn't simulate.) > > Am I just overlooking something simple? (If so, what's the > magic word.) > > -- > The suespammers.org mail server is located in California. So are all my > other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited > commercial e-mail to my suespammers.org address or any of my other addresses. > These are my opinions, not necessarily my employer's. I hate spam. >
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