Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
I hate Quartus, but don't want to wait for the S3E kit anymore... Anyone have experience with this guy? http://www.altera.com/education/univ/materials/boards/unv-de2-board-distributors.html > > S3e starterkit will be > > available Feb 2005, it only says 'targetted' meaning : nothing at allArticle: 93951
Monte Dalrymple wrote: > > Yes, Shima's schematics were a nightmare to try to understand, > given that he only drew transistors, and there were only signal > names for signals that left a sheet... Does anyone know anything about the Z80'000 that I've got a prelim datasheet/usermanual for? It seemed like a chip ahead of its time... -- [100~Plax]sb16i0A2172656B63616820636420726568746F6E61207473754A[dZ1!=b]salaxArticle: 93952
Ivan Wagner <ivan.wagner@gmail.com> wrote: > Doesn't your synthesis tool show you the logic blocks used for your > code after targeting the FPGA? The ISE does have a graphical logic block output but it failed even when synthesizing the code in XST. The only result we have for this code is from dc_fpga on Unix platform. Since I use a pure CLI environment, I don't know if it will generate any graphical result. Any info about this is welcomed. Yes, I know I can go to FPGA editor for everything, but it too complicate. > > In our case at school, uscing a Cyclone II FPGA from Altera, Quartus II > synthesis tool gives you a graphical output showing you exaclty how > much logic, where and routing. > > Cheers. > -- Regards, Tsoi Kuen Hung (Brittle) CSE CUHKArticle: 93953
> Does anyone know anything about the Z80'000 that I've got a prelim > datasheet/usermanual for? It seemed like a chip ahead of its time... The Z80 matched its time and became hugely popular. I don't know about the Z8000, may be it remained not that popular because it was ahead of its time (generally, products ot people ahead of their time have the destiny of simply not being understood by the majority of their time), and then may be it had to compete with other designs, like the 68k etc. Well, the 8086 became popular in spite of the 68k and the Z8000 can't possibly have been such a mess as the 8086 was (is), so the reason(s) may have been completely different, perhaps (likely, I believe) not technical at all. I hope Peter, Monte and perhaps others who have been involved could shed some light. (I am also curious about the story, but I don't know the Z8000 so I would appreciate an educated judjment). Dimiter ------------------------------------------------------ Dimiter Popoff Transgalactic Instruments http://www.tgi-sci.com ------------------------------------------------------Article: 93954
Well first off, I'd like to thank all the people who answered this. This group seems to be much helpful than comp.os.linux :D Regarding to the maths... well yeah what I'm saying is this. It's like college physics: When you learn theory you see all those scary derivates and integrals and greek letters that don't seem to make any sense. But in practice, there are just multiplications and divisions and things like that. So what I think is that there must be some practical way that just involves a few calculations and you are set. Or at least a computer program that can help. I keep my HP 49G handy in case something gets too nasty ;). Anyways I have yet to take calculus 2 where they teach the fourier series (which I think will help me a lot with this, right?). Right now I'm studying to take the final for computers architecture. I'm writing programs in machine language and designing adders and multipliers that work in BCD or gray code. So to "Symon"... this few years of fiddling with microcontrollers and FPGAs have helped me a lot. Sometimes it's easier (or better) to learn with practice than sitting and making exercises on a book. :) To implement the DSP things... I found what I think it's an easier solution: Nullsoft DSP Studio... that is, the DSP that comes with Winamp. It provides you with the current sample and then you can manipulate it and return it to Winamp. It then plays it back through the speakers. Who would have thought that a music player can help you learn DSP? As for the A/D converters, TI seems to have quite a few audio ADCs and DACs, and they have provided me some free samples in the past ;) Again thanks everyone for answering. Hern=E1nArticle: 93955
Didi wrote:
> > Does anyone know anything about the Z80'000 that I've got a prelim
> > datasheet/usermanual for? It seemed like a chip ahead of its time...
The Z80,000 was after my time. So I have nothing to say about it.
The Z8000 appeared right after the 8086, and almost simultaneously with
the 68000 by Motorola, all 3 were 16-bit microprocessors. And the race
was on!
The 8086 won because IBM picked its baby-brother, the 8088, for the PC,
and because of Intel's massive marketing campaign ("operation Crush"),
against the cleaner and technically superior 68000. Never underestimate
Intel's marketing muscle. It was a brutal campaign. There is a book
about it, by Mr Davidov, the Intel marketing guy.
The Z8000 became condemned to a back-water existence. It was smaller
and simpler and thus potentially cheaper than the 68000, but (like the
8086) it partitioned the memory space into 64K segments, and there was
no way to detect when the address counter rolled over. Ziliog used
arrogant and semi-religious arguments for memory partitioning (the chip
architect really believed that it was a great feature, not a handicap),
but the upcoming graphics applications preferred a linear address
space, and they all went to the 68000.
The Z8000 was left with military and some arcade-game designs.
My only encounter with Steve Jobs was when I tried (unsuccessfully) to
convince him to use the Z8000 instead of the 68000 for what soon became
the Macintosh. The 68000 came in a gigantic package, and just its gold
plating cost almost as much as the Z8000 die. But the linear addressing
won...
Of the three contenders, the obviously worst one became the winner. The
68000 did so-so, and the cleanest and leanest became the loser. Who
says life is fair?.
Peter Alfke, reminiscing.
Article: 93956
On 2006-01-04, Didi <dp@tgi-sci.com> wrote:
> The Z80 matched its time and became hugely popular. I don't
> know about the Z8000, may be it remained not that popular
> because it was ahead of its time (generally, products ot
> people ahead of their time have the destiny of simply not
> being understood by the majority of their time),
The Z8000 just didn't happen to make into anything like the PC
or the Macintosh. IIRC, it was used in a fair bit of
industrial, telecom, and military gear. I never used the Z80K,
and don't remember much about it other than it was a full
32-bit architecture with cache, a pipeline, and a paged MMU. (I
do remember seeing some datasheets). It took Intel years
before they had anything even approaching the Z80K.
> and then may be it had to compete with other designs, like the
> 68k etc. Well, the 8086 became popular in spite of the 68k and
> the Z8000 can't possibly have been such a mess as the 8086 was
> (is),
The Z8000 was a very nice architecture. Very PDP-11-like. Far,
far, better than that dog's-breakfast that Intel puked up and
named the 8086. It had a nice large set of registers (16x16bit
registers that could also be used as 8x32 bit and I think
4x64bit). The instruction set was very regular (more so than
even the 68K). The Z8000 daisy-chained interrupt scheme was an
utter dream to work with compared to the nightmare that was the
8259 -- which was an obsolete piece of crap when it was
introduced in 1980 or whenever it was. There's a very special
place in hell reserved for whoever put that bit of waste into
the IBM PC. The Z8000 (like the Z80) included a built-in DRAM
refresh controller. The Z8000 also had some very nice
peripherals in the Z8036 counter/timer/PIO chip, the Z8030 dual
sync/async UART, the Z8010 MMU. The Z8530 (the version of the
8030 with the muxed bus) is still widely used today.
IIRC, the Z8000 didn't have a version with an 8-bit external
bus like the 8088 or the 68008, so that limited it's
application in cost-senstive products. The CPU and the
peripherals were all NMOS and were pretty high power (about
200mA each, IIRC). That didn't help much.
Here's are a couple nice pages:
http://www.old-computers.com/history/detail.asp?n=52&t=3
http://www.kranenborg.org/z8000/
Apparently the Z8000 is still shipping in CMOS as the Z16C00
series.
> so the reason(s) may have been completely different, perhaps
> (likely, I believe) not technical at all. I hope Peter, Monte
> and perhaps others who have been involved could shed some
> light. (I am also curious about the story, but I don't know
> the Z8000 so I would appreciate an educated judjment).
--
Grant Edwards grante Yow! I just heard the
at SEVENTIES were over!! And
visi.com I was just getting in touch
with my LEISURE SUIT!!
Article: 93957thank you everybody... for the helpful suggestions. so basically, using edk is a must, huh? it's just that i got this on simple pulse counting peripheral to work - but when i added an extra state to disable counting before a certain 'start' signal is asserted, it goes zilt! nothing! from my crude debugging procedures i suspect that the state machine is at an unknown state! well, back to the drawing board! :( thanks again.Article: 93958
hii... i'am using modelsim PE. you saying its a command line interface, are there any commands as such that interfaes directly with the vhdl file, suppose the vhdl file that has to be verified is d_ff.vhd. should i even have the testbench file along with this or just need the d_ff.vhd file. and now to interface the script with this ie.. with the vhdl file what should be done. should any command be used in vsim. how can i force values to the signals, view the wave form using the command add wave. can you plzz help me, as in my company i should learn this on my own, i'am a trainee and have to get this concept clear soon. can u please give me a example using a D Flip-Flop. it would be great n really appreciated if you help me out.. Thanks.. thanks Hans A Very "Happy New Year 2006" to you & your family!!! May this year bring in Peace, Happiness, Prosperity & Good health!!!!Article: 93959
Now, My project of the Dynamically Reconfigurable FPGA is A dynamically reconfiguration Up/Down counter. I show the number of counter for 7 segment LEDs. But, I can't show it when my partial bitstream load up FPGA. Alan ChenArticle: 93960
First off, let me point out that I'm a newbie trying to teach
myself verilog. :)
I get warnings (shown below) whenever I try to assign values to a register
in a "always @ (posedge clk)" block, and change the values in a "always @
(negedge clk)" block.
My thinking is that I want to update an internal register on the negedge,
and then present it to the output on the posedge. I'm pretty sure that my
thinking is wrong because if I "`ifdef" out the negedge block the
warning goes away. [The logic also stops working, but that's not the point.]
As a final note, this logic simulates just fine.
Thanks for looking at this for me. I appreciate the help.
-MO
module top(clk, reset, enable, cnt);
input clk,reset,enable;
output cnt;
wire clk,reset,enable;
reg [3:0] cnt, curval, ov1;
reg [1:0] acnt;
always @ (posedge clk) begin
if (reset) begin
curval <= 5;
end
else begin
case (acnt)
0: cnt <= curval;
1: cnt <= ov1;
2: cnt <= 2;
3: cnt <= 3;
endcase
if (!enable)
acnt <= acnt + 1;
end
end
// Update the values
always @ (negedge clk) begin
if (enable) begin
ov1 <= curval;
curval <= curval + 1;
end
end
endmodule
Here are warnings I get when trying to synthesize the above code:
INFO:Xst:1304 - Contents of register <curval> in unit
<top> never changes during circuit operation. The register is replaced by
logic.
WARNING:Xst:1426 - The value init of the FF/Latch curval_2 hinder the
constant cleaning in the block top.
You should achieve better results by setting this init to 1.
WARNING:Xst:1426 - The value init of the FF/Latch curval_1 hinder the
constant cleaning in the block top.
You should achieve better results by setting this init to 1.
WARNING:Xst:1710 - FF/Latch <curval_3> (without init value) has a
constant value of 0 in block <top>. WARNING:Xst:1895 - Due to other
FF/Latch trimming, FF/Latch <curval_0> (without init value) has a
constant value of 0 in block <top>. Register <ov1_3> equivalent to <ov1_0>
has been removed Register <curval_2> equivalent to <curval_1> has been
removed Register <ov1_2> equivalent to <ov1_1> has been removed
ERROR:Xst:528 - Multi-source in Unit <top> on signal <N0>
Sources are:
Signal <curval<3>> in Unit <top> is assigned to GND
Signal <N0> in Unit <top> is assigned to GND
Signal <curval<0>> in Unit <top> is assigned to VCC
ERROR:Xst:528 - Multi-source in Unit <top> on signal <curval<1>>
Sources are:
Output signal of FDE_1 instance <curval_1>
Signal <curval<1>> in Unit <top> is assigned to GND
Signal <curval<2>> in Unit <top> is assigned to VCC
CPU : 6.59 / 15.27 s | Elapsed : 8.00 / 9.00 s
-->
Total memory usage is 66588 kilobytes
Number of errors : 0 ( 0 filtered)
Number of warnings : 4 ( 0 filtered)
Number of infos : 1 ( 0 filtered)
ERROR: XST failed
Process "Synthesize" did not complete.
Article: 93961Mike Oxlarge wrote: > First off, let me point out that I'm a newbie trying to teach > myself verilog. :) > > I get warnings (shown below) whenever I try to assign values to a register > in a "always @ (posedge clk)" block, and change the values in a "always @ > (negedge clk)" block. > > My thinking is that I want to update an internal register on the negedge, > and then present it to the output on the posedge. I'm pretty sure that my > thinking is wrong because if I "`ifdef" out the negedge block the > warning goes away. [The logic also stops working, but that's not the point.] > > As a final note, this logic simulates just fine. > > Thanks for looking at this for me. I appreciate the help. > > -MO- -snip- I would guess that you're working with a chip that only supports clocking on one edge of any given clock line. If you want to implement a two-phase clock you'll probably have to do it explicitly. On recent Xilinx parts it looks like you can do this more or less directly with a DCM or a DLL -- figuring out how is up to you. -- Tim Wescott Wescott Design Services http://www.wescottdesign.comArticle: 93962
On Tue, 03 Jan 2006 22:47:53 -0800, Tim Wescott wrote: > I would guess that you're working with a chip that only supports > clocking on one edge of any given clock line. If you want to implement > a two-phase clock you'll probably have to do it explicitly. > > On recent Xilinx parts it looks like you can do this more or less > directly with a DCM or a DLL -- figuring out how is up to you. Thanks for the speedy reply. I'm working with the XS3S200 Spartan 3 device, on a Spartan-3 starter board. I'll have to do some digging in the docs to see if what you've suggested is true for my device. Thanks again.Article: 93963
Peter Alfke wrote:
> Didi wrote:
>
>>>Does anyone know anything about the Z80'000 that I've got a prelim
>>>datasheet/usermanual for? It seemed like a chip ahead of its time...
>
>
> The Z80,000 was after my time. So I have nothing to say about it.
>
> The Z8000 appeared right after the 8086, and almost simultaneously with
> the 68000 by Motorola, all 3 were 16-bit microprocessors. And the race
> was on!
>
> The 8086 won because IBM picked its baby-brother, the 8088, for the PC,
> and because of Intel's massive marketing campaign ("operation Crush"),
> against the cleaner and technically superior 68000. Never underestimate
> Intel's marketing muscle. It was a brutal campaign. There is a book
> about it, by Mr Davidov, the Intel marketing guy.
..Or Intel's manufacturing muscle - once the IBM PC selected the x88, it
really was Game Over, and helped a lot more by Microsoft's marketing
Muscle, than Intel's.
>
> The Z8000 became condemned to a back-water existence. It was smaller
> and simpler and thus potentially cheaper than the 68000, but (like the
> 8086) it partitioned the memory space into 64K segments, and there was
> no way to detect when the address counter rolled over. Ziliog used
> arrogant and semi-religious arguments for memory partitioning (the chip
> architect really believed that it was a great feature, not a handicap),
> but the upcoming graphics applications preferred a linear address
> space, and they all went to the 68000.
> The Z8000 was left with military and some arcade-game designs.
> My only encounter with Steve Jobs was when I tried (unsuccessfully) to
> convince him to use the Z8000 instead of the 68000 for what soon became
> the Macintosh. The 68000 came in a gigantic package, and just its gold
> plating cost almost as much as the Z8000 die. But the linear addressing
> won...
>
> Of the three contenders, the obviously worst one became the winner. The
> 68000 did so-so, and the cleanest and leanest became the loser. Who
> says life is fair?.
> Peter Alfke, reminiscing.
~68000 is still alive, in Coldfire microcontrollers, but if the Z8000
had 64Kpages, it was too similar to the x86, and also too late to use
the code base the x86 then had.
The Key in all this, is Intel was able to make, and ship x88 silicon,
while the others were sampling, and/or unable to meet price targets.
There was also a time, back then, when better code size mattered
due to the price of memory.
These days, the 64K issue appears again in the microcontroller sector-
most 16 bit cores naturally have 64K opcode reach issues - and we
see a swing into 32 bit microcontrollers : memory is far cheaper today.
An interesting 'inversion' is the sight of a mere 8K code variant
ARM from Philips - LPC2101.
-jg
Article: 93964That are good news :o) Rgds Andr=E9Article: 93965
On Tue, 03 Jan 2006 22:34:02 -0800, Mike Oxlarge <oxlargeMike@yahoo.com> wrote: >My thinking is that I want to update an internal register on the negedge, >and then present it to the output on the posedge. To be frank I don't think your issue is whether your chip supports mixed edge clocks etc but basic logic design background. To do regular digital logic you don't need mixed edges as you describe above. The flops already do that for you internally. You need to partition your design into combinational blocks and storage and you use the flop as a storage element which samples its input every clock edge and presents it to the output. Your combinational blocks also depend on the current value of the storage but as you need an edge for it to be sampled the loop is cut at the input of the flop so to speak. You don't need a two phase implementation which necessiates mixed clock edges. You can do everything you need with a single edge. Imagine a cloud of logic which takes your enable and the cnt value and calculates the next value of cnt to be presented. When the clock edge happens this value gets to the flop output and the cycle starts again. No need for an internal phase. HTH.Article: 93966
I was at Onyx Systems in 1980 doing the Unix V7 port for the machine that spring to meet the NCC dedline at the begining of that summer. The Z8002 had just finally became stable for a multitasking OS. We shipped a few thousand of them before Carl Berg pulled the plug on the UNIX management team wanting more MPM/CPM machines. Carl funded Onyx to sell IMI 8" disk drives, another of his venture companies. While the Z8002 easily ran PDP-11 applications that were ported to it .... larger address space applications developed for Vax, PDP10 & 20, and IBM main frames suffered horribly due to the segmentation. Motorola's M68K wasn't stable yet, but did become stable about a year later while I was at Fortune Systems doing design work on that machine. After years of living in segmented architectures and crippled address spaces on small machines, the M68K was the first microprocessor that would actually handle large address spaces cleanly to compete head on with Dec Vax and PDP10 & 20 lines. Fortune took the 32:16 to Comdex in the fall of 1981 and took best of show as the classy high performance multiuser desktop UNIX box. IBM release the PC, at about 30% the performance just weeks earlier with it's new OS .... PCDOS (soon to be also sold by it's supplier as MSDOS). While doing the M68K unix there was a LOT of pressure to find some Z80 CPM/MPM compatability and migration path for applications developed for those platforms. By late spring 1982 the demand to CPM/MPM compatability was completely dead, as that market died in it's foot steps as IBM shipped more PC's than all the Z80 machines that existed in 1982. Going to market with the largest computer companies sales team competing against you is a very tough sell. Now the next part of the story is the part that very few people understand ... and probably the most important part never to forget .... and that is that ....Article: 93967
Hi,
your question(s) target a lot of different topics and some are more a
matter of opinion than plain facts. Let's try to answer them piecewise.
> Does anyone happen to know what will the following (software) code
> will look like after going through a synthesis tool?
Most likely not, since the two codes are not identical and have errors:
> reg [15:0] data_in[127:0]; // input
is not the same as
> signal data_in : std_logic_vector (127 downto 0); -- input
and
data[...] in the if-statements is not declared anywhere.
> I was told, back in the school, that never use *HDL as a software
> language and should have a block diagram or data path before coding.
>
That is basically right. Focus on "as a software language" !
Search this group for "think hardware" and from these posings you will
see what's the difference. (After this have a look at your code again)
Nonetheless you can write synthezizable
behavioral descriptions of your hardware, if you know how to.
> But it seams that more and more people trust the synthesis tool
> rather.
Some just trust and fail, others understand what the tools are doing
with the sources and succeed.
> If I was to implement the above circuit, I will not write the above
> codes.
I hope so :-)
> I will first draw a data path diagram which show me that I can have
> have a barrel shifter to map the 16-bit 'we' to 64-bit 'data_we'
> based on the 'offset' input. Than I will use another shifter to
> "expand" the data and assign each of the 64 slots based on the
> 'data_we'. I may even write a simple Perl script to generate this 64
> statement.
While I saw from the sources that you want to implement some
barrelshifting thing I failed to understand to understand the shift
control. It just looked strange, but may be ok for the desired purpose
and just clumsy coded.
Drawing a scetch of the circuit you are about to design will always be
the first step, even if you are going to use a HDL because you need to
understand the circuit and how it should work.
Then, if you understand your prefered HDL, you can code it straight
away. Of course you can use PERL to generate repeating HDL statements,
but it may also be possible to use loops to achieve the same result with
less HDL.
> Does anyone know any better implementation scheme or any synthesis
> tools that will generate a better result base on the above code? I
> tried Xilinx XST and the above code failed (out of memory ?!) I know
> some other synthesis tool can generated a valid circuit with terrible
> performance.
Well, that probably is the fault of your source, and not of the tools.
As you stated above HDLs should never be used as a software language,
and that's what you did. Use it as a Hardware Description Language for
synthesis and everything will be fine. One of our students once had a
similar problem with some code that was announced as "synthesizable". It
failed on ISE due to memeory problems and it took Synopsys DC several
days(!) to create an ultralarge circuit. After recoding the design from
scratch (but still with lots of behavioral statements) we got a nice
small and fast circuit.
> The most important question is, "Should I worry about this?" Someone
> told me that the code failed to compile just because XST is not good
> enough. But I wonder.
I have done (small) barrel shifters before with XST and lots of other
stuff and it works well. While there were problems with array-synthesis
in the past (not supported by XST) you should think about using arrays
anyway.
> My teammates and me have a different point of view in CAD tools. They
> believe the logic optimization (e.g. from behavioral description to
> netlist) and don't trust the physical optimization (e.g. they do hand
> placement and timing on every net). I believe the opposite.
Both have advantages and disadvantages, depending on the problems you have.
HDLs may speed up your design time, because the tool does all the
optimisation etc. But if performance is your ultimate goal (e.g. for
high volume products to reduce costs) then you may reach a point where
you can't evade "handywork". Which approach works out best depends on
too many factors. So there is no simple answer to that question.
> There are too many *information* available when running the placement
> and routing process which is NOT suitable for a human brain. But the
> tools can handle this well. There some *knowledge* in the design
> which is hard to be captured in the tools. And we engineerings are
> trained to use this knowledge to optimize our design. So I believe
> that we should code more careful rather than pumping constraints to
> the tools.
That's just the point :-)
> But the current trend is (at least observed by myself), to encourages
> users code more like in a software environment. Is this the design
> flow for tomorrow or I misunderstand something?
The question is: Who has set this trend, and who's going to follow it?
For academic or research purposes where you have a single multi million
gates FPGA to test you design ideas in hardware this might be right and
useful. (Think of it as synthesizable simulation acceleration)
But product designs have different goals.
Now, think where the engenieering newbies come from... :-)
Have a nice synthesis
Eilert
Article: 93968"Pierre" <pierre.remy@gmail.com> schrieb im Newsbeitrag news:1136341157.194576.111400@g43g2000cwa.googlegroups.com... >I hate Quartus, but don't want to wait for the S3E kit anymore... > Anyone have experience with this guy? > > http://www.altera.com/education/univ/materials/boards/unv-de2-board-distributors.html > >> > S3e starterkit will be >> > available Feb 2005, it only says 'targetted' meaning : nothing at all > no hands on experience but I would recommend the TREX C1 for 149USD its pretty much loaded, also for that board the design guru of the "C1 reconfigurable" computer is providing amstrad emulation with lots of games working from the CF card, etc.. both the DE and C1 board have on board byteblaster that is also useable for customer applications for USB comms so that pretty nice. digilent s3e starterkit includes platform usb cable, but that is only useable for config not for user API access as said I dont have the TREX board so I am only commenting on what I have seen or heard. AnttiArticle: 93969
ok, sorry for the brief break ... in 1980 Wang was chewing up the minicomputer office market with several machines that had the premier word processing system in use in most large offices, especially the legal office market. Selectric typewriters had for a decade been the machine of choice, as it's bail lock keyboard had THE TOUCH for speed typists, as you quickly learned not to bottom keys, but release on fall thru greatly reducing finger shock by not having to bottom keys or take the recoil from the key hitting paper in your finger tips. The problem was that these typewriters were expensive to buy, and due to high maintence from the rotate tapes and complex timing they were much more complex than the standard Royal or other common typewriter. Plus, they were multi-pitch and multi-font adding a new look to business communications. Enter word processing, daisy wheel printers, and electronic document storage and editing, and Wang had a gold mine, for about the cost of a high end selectric. IBM decided it had to compete in this new market, and in the summer of 1980 release the Display Writer, a computer based document system using the 8086 at a cost of about $8K for a single station, and about $26K in the 3 station version. The story was that IBM traded Intel bubble memory patents for the rights to the 8086 so IBM could mfg it's own processor chips. During that same spring another group in IBM was working on the PC, and decided to use the same processor design, that they already had rights too. So the Z8000, which wasn't stable yet, really was never a contender ... nor the M68K which wouldn't be stable for another year or so. At this same time, high quality glass terminals, like the Datamedia DT80, were roughly $2K list, and low end glass terminals like the ADM-3A where just under a grand list. Similar prices for fully configured Radio Shack TRS-80 systems, especially the TRS80 Model 2 which was the high end machine. IBM releases the PC priced at just under $2K with dual floppies, with PCDOS and inside a few months all the large Z80 programs are being ported to the PC ... especially several key word processing applications, which combined with a high end daisy wheel printer, creates an affordable word processing solution at about the same price as a good Selectric ... and a much cheaper maintence contract. IBM killed two cash cows ... the selectric typewriter and the Displaywriter without realizing what they had done. IBM sales was giving away PC's with a huge institutional discount at just above ADM-3A prices, which combined with 3270 emulation software, also destroyed IBM's mainframe terminal business. By perchasing PC's in volume, institutional and other large buyers, were able to ratchet down IBM's multi-tiered pricing to get huge discount on IBM minicomputer and mainframe products. As a result, thousands of PC's sat every where, unopened, just to get huge prices savings on big ticket purchases. This lead to discount grey market channels for PC's, and even lowered the street price to accellerate the comdity PC word processing market. Replacing over a decade of selectric typewriters, and several years of high end Z80 business computers, with 16 bit processors took about 18 months during 1982 and early 1983, and then the market saturated. The first huge computer tech buble ended with the tech crash in 1983. That further fuelled depressed computer prices as a huge over production inventory was liquidated at fire sale prices. With the market very flat, depressed sales, depressed prices, it took the industry the next two years to retool, reengineer, and come out of that down turn with much better products that took another 5 years to saturate the market as demand for word processing, business computers, and home computers really became mainstream.Article: 93970
hi I have another question about DCM's: If I use the design wizard to generate a vhdl file for a DCM the wizard uses all kinds of Buffers. For example it also uses a "BUFG" in the feedback loop. CLK0 -> BUFG -> CLKFB. Is that necessary? Do I have to use an IBUFG for the CLKIN of a DCM if nothing else is connected to that CLK signal? I still a beginner in vhdl so please bear with me. Thanks for all the help urbanArticle: 93971
Hi Hernan, So, Symon is my real name, I just had a sixties' mother! It's not "Symon"! ;-) I'm glad you learned about microcontrollers hands-on. My point is that I bet you didn't try to fiddle with microcontrollers without first learning how to use a PC. FWIW, my own experience is that you'd be better off learning the maths first before you design DSP algorithms. Austin makes a great point in that there are many tools nowadays that let you play with the mathematics which could give you a good start! Anyway, good luck whatever you choose! Cheers, Syms. p.s. As for newsgroups, folks are quite friendly on comp.dsp too. "drg" <drgenio@gmail.com> wrote in message news:1136347943.648657.30110@g14g2000cwa.googlegroups.com... Anyways I have yet to take calculus 2 where they teach the fourier series (which I think will help me a lot with this, right?). Right now I'm studying to take the final for computers architecture. I'm writing programs in machine language and designing adders and multipliers that work in BCD or gray code. So to "Symon"... this few years of fiddling with microcontrollers and FPGAs have helped me a lot. Sometimes it's easier (or better) to learn with practice than sitting and making exercises on a book. :)Article: 93972
Hi all:
I'm pleased to announce the release of MyHDL 0.5.
MyHDL is an open-source package for using Python as a hardware
description and verification language. Moreover, it can convert
a design to Verilog. Thus, MyHDL provides a complete path
from Python to an FPGA implementation.
MyHDL 0.5 has many new features, in particular with regard to
conversion to Verilog. The converter automates certain tasks
that are hard in Verilog directly. The Verilog output code
works well with popular FPGA synthesis tools.
For a complete overview, go here:
http://myhdl.jandecaluwe.com/doku.php/overview
The manual is here:
http://www.jandecaluwe.com/Tools/MyHDL/manual/MyHDL.html
To find out the details of what's new, go here:
http://myhdl.jandecaluwe.com/doku.php/whatsnew:0.5
You can download the release from SourceForge:
http://sourceforge.net/project/showfiles.php?group_id=91207
Best regards,
Jan Decaluwe
--
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
Losbergenlaan 16, B-3010 Leuven, Belgium
From Python to silicon:
http://myhdl.jandecaluwe.com
Article: 93973Hi All: I have project of the Reconfiguration.I saw the paper "A Module-Based Dynamic Partial Reconfiguration" and maked the same project. In my project(it is a up / down counter), I had a addition partial bitstream (up counter)and a subtraction(down counter) bitstream and a top routed bitstream. When I loaded up partial bitstream with FPGA,the counter could work correct , but when the partial bitream loaded up FPGA the counter was halt. Someone can tell me what's wrong with it? I used xc2s200 ,ISE 6.2i Alan ChenArticle: 93974
There's Verilog and there's synthesizeable Verilog. Not everything you can write in Verilog turns into sensible hardware. The basic rules for syntheizeable code are that only a single block can drive a register unless tristates/multiplexors are used. You update curval on both edges. Perhaps the curval reset logic should be done on the negedge ? Jon
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