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
Hal Murray wrote: > 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.) > Doesn't Webpack include a language template help? (It is marked with a lit lamp on the tool bar). If it does you may find some templates. However I would suggest you to look for application note XAPP463 at Xillinx' page. There are zip files with vhdl/verilog code you may simply copy and paste and adapt to your needs. HTHArticle: 75726
Elder Costa wrote:
> Hal Murray wrote:
>
>> 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.)
>>
>
> Doesn't Webpack include a language template help? (It is marked with a
> lit lamp on the tool bar). If it does you may find some templates.
> However I would suggest you to look for application note XAPP463 at
> Xillinx' page. There are zip files with vhdl/verilog code you may simply
> copy and paste and adapt to your needs.
The online documentation at
http://toolbox.xilinx.com/docsan/xilinx6/books/manuals.htm
has it as well. I drilled down through XST User guide -> HDL Coding
techniques -> RAMs/ROMs. This lead me here:
http://toolbox.xilinx.com/docsan/xilinx6/books/data/docs/xst/xst0026_5.html#wp325264
which shows how to infer the ROM. I'm sure you could also instantiate
it, but to me, that actually seems harder than inferring.
Marc
Article: 75727does anyone have a code for this? i will be using pwm for controlling a servo motorArticle: 75728
Rick, That sounds like the approach that I was considering, as the reads seem to be okay, it's the writes that become unstable, however if I am delaying the write strobe, then I must also delay the data lines, and the address lines, otherwise the micro has moved on to the next cycle without the data being written correctly. It would seem to me that I must pipeline the write transfer to eliminate the instability. Thanks for the help. Jason "rickman" <spamgoeshere4@yahoo.com> wrote in message news:41945E21.F7E5544F@yahoo.com... > Jason Berringer wrote: > > > > Hello all, > > > > I have a microcontroller running at 40 MHz that performs asynchronous bus > > transfers, and I have an FPGA running at 100 MHz. With talk of metastability > > and all I would conclude that sending some of the control signals through > > flip flops (say 2 levels) would eliminate any metastability. The question > > then becomes how do I keep the bus transfers short enough without incurring > > significant delays between registering a read command (for example) and then > > responding to it and placing the data on the bus to be read. This would have > > 2 clock cycles to eliminate the metastability on the read signal (and > > address lines if I want to worry about metastability with those lines) and > > then at least one more for the data to be placed on the bus, a total of > > three clock cycles. That is too much time to get the data on bus (if I'm > > trying to keep the bus cycles short). I would appreciate some advice on how > > others have handled transferring data between an asynchronous device and an > > FPGA. > > > > Would it not be acceptable to make an asynchronous interface block for the > > FPGA, and then pull it into the synchronous world inside the chip? This > > seems to go against the metastability thoughts that I've come across. > > I designed something similar and found it was not a big problem. You > don't have to worry about metastability on the read as long as you are > not doing anything else with the strobe internally. Even though the > read enable or address may be changing on a clock edge, that first cycle > will be ignored by the CPU and 10 ns later the second clock cycle will > read valid data from the RAM in the FPGA. > > On the write you should use a register to hold the data when the write > strobe is asserted. The stabilized (and delayed) write strobe can write > the data into your RAM. If your data is not stable on the leading edge > of the write strobe, you can use one of the delayed strobes to as your > data register enable. That will help you meet both setup and hold. > > -- > > Rick "rickman" Collins > > rick.collins@XYarius.com > Ignore the reply address. To email me use the above address with the XY > removed. > > Arius - A Signal Processing Solutions Company > Specializing in DSP and FPGA design URL http://www.arius.com > 4 King Ave 301-682-7772 Voice > Frederick, MD 21701-3110 301-682-7666 FAXArticle: 75729
Ultimately in the design I start with one 10 MHz TCXO and use PLL chips to generate a 40 MHz clock (micro) and another 100 MHz clock (FPGA). Since there are no handshaking lines between the chips for data transfers I cannot use. I have not checked the relationship between the two clocks, as I wanted just assume they were completely asynchronous for the design, thus allowing this design to work in any situation. 32 bit micro is what I'm using. Thanks for the help. Jason "AnonymousFC3" <no_email@please.net> wrote in message news:ur2dnUd9XqlOlQncRVn-vQ@comcast.com... > Jason: > It would be nice to have more specifics on your problem. > > Inherently ther is no difference between an FPGA (which one) and anything > else. > > Which kid of metastability? > Which kid of microcontroller? > Do you use the same clock, and derive one from another ? (I guess no). > Here having somewhat synchronous clocks simplify the problem, but async > transfers are ok... as long as you do not violate any timing requirement > (mostly cpu/memory). > I would suggest to derive one clock from another if you could. > The somewhat brute force way to resolve this issue would be to use of FIFO's > between busses but you probably can do better. > There is no way you can avoid a proper assessment of timing closure! > -- > All the luck. > > Jason Berringer wrote: > > > Hello all, > > > > I have a microcontroller running at 40 MHz that performs asynchronous bus > > transfers, and I have an FPGA running at 100 MHz. With talk of > > metastability and all I would conclude that sending some of the control > > signals through flip flops (say 2 levels) would eliminate any > > metastability. The question then becomes how do I keep the bus transfers > > short enough without incurring significant delays between registering a > > read command (for example) and then responding to it and placing the data > > on the bus to be read. This would have 2 clock cycles to eliminate the > > metastability on the read signal (and address lines if I want to worry > > about metastability with those lines) and then at least one more for the > > data to be placed on the bus, a total of three clock cycles. That is too > > much time to get the data on bus (if I'm trying to keep the bus cycles > > short). I would appreciate some advice on how others have handled > > transferring data between an asynchronous device and an FPGA. > > > > Would it not be acceptable to make an asynchronous interface block for the > > FPGA, and then pull it into the synchronous world inside the chip? This > > seems to go against the metastability thoughts that I've come across. > > > > Any and all comments would be appreciated.. > > > > Thanks, > > > > Jason >Article: 75730
Jim, Yes it does (XC2S200), but I have no access to the 40 MHz clock from the micro, otherwise I would have implemented a synchronous transfer or used the dual port RAM. I figured that without access to the 40 MHz clock the dual port RAM would be out of the question since I would need a clock one the second port which I do not have. Thanks Jason "Jim Granville" <no.spam@designtools.co.nz> wrote in message news:rXTkd.952$3U4.83723@news02.tsnz.net... > Jason Berringer wrote: > > Hello all, > > > > I have a microcontroller running at 40 MHz that performs asynchronous bus > > transfers, and I have an FPGA running at 100 MHz. With talk of metastability > > and all I would conclude that sending some of the control signals through > > flip flops (say 2 levels) would eliminate any metastability. The question > > then becomes how do I keep the bus transfers short enough without incurring > > significant delays between registering a read command (for example) and then > > responding to it and placing the data on the bus to be read. This would have > > 2 clock cycles to eliminate the metastability on the read signal (and > > address lines if I want to worry about metastability with those lines) and > > then at least one more for the data to be placed on the bus, a total of > > three clock cycles. That is too much time to get the data on bus (if I'm > > trying to keep the bus cycles short). I would appreciate some advice on how > > others have handled transferring data between an asynchronous device and an > > FPGA. > > > > Would it not be acceptable to make an asynchronous interface block for the > > FPGA, and then pull it into the synchronous world inside the chip? This > > seems to go against the metastability thoughts that I've come across. > > > > Any and all comments would be appreciated.. > > Does the FPGA not have DualPort RAM blocks ? > -jg >Article: 75731
counter, comparator, ... When this is done, go the the newsgroup about servo's and ask how to do the control loop. "iceman" <static123ph@yahoo.com> wrote in message news:62011d8f.0411130625.ef256ae@posting.google.com... > does anyone have a code for this? i will be using pwm for controlling a servo motorArticle: 75732
"iceman" <static123ph@yahoo.com> wrote in message news:62011d8f.0411130625.ef256ae@posting.google.com... > does anyone have a code for this? i will be using pwm for controlling a servo motor http://www.fpga4fun.com/RCServos.html AnttiArticle: 75733
Hi just some short info what was at Electronica 2004 (they way I did feel and see things there) Xilinx - I did see the ML401 board running an OS from the CF card using standard PC peripherals (keyboard monitor) - well it's my opinion of course but anyone considering buying some other V4LX25 based starterkit/eval board should think twice and see if he can get ML401 instead, its real nice board packet with all you wanna have peripherals (all that make sense for V4-LX) As per Xilinx ML401 boards "ARE SHIPPING" - as of other information Avent and Memec are not yet shipping their V4 starterkits, at least I have not information about anyone receiving Avnet/Memec V4 board, I know there are pending order for both, and both Memec/Avent are promising to start deliveries (really) soon. ML461 was also there, its real HUGE board! Well I guess anyone testing the memories and memory controllers have already placed their orders. There is expected a low cost S3-1500 board (Digilent) with "feature packed peripherals" - no further info but my guess price tag $199-$299 Altera - "Wasnt there" as of general feeling at Xilinx booth - this was almost true, a small Altera booth was at the fair, but very hidden at the Automotive hall. Altera seems to cover it all by "one size fits them all" approuch - they only had "Large" T-shirts (no options), and a special calculator to help engineers to get Altera equivalent to all other FPGA's, a few examples: XC2VP100 -> EP1S80 XC2V80 ->EPM1270G (* secondary choice) APA75 -> EP1C3 AX2000 -> EP1C20 [...] -> [...] Great tool! Now we can buy Altera parts for all our needs! Ah, sorry some useful info too: First MAX2 chips in TQFP package are expected JAN 2005 Actel - Great expresso at the booth! And.. my mouth is shut :( (I did see there someone and something unexpected) Synplify - ver 8 due Jan 2005, Actel Proasic is not and will not be supported by Amplify Mentor - Got Modelsim Designer 6.0 mini CD (not sure whats on it) Altium - All busy explaining visitors how to route a wire, the new V2Pro nanoboard module was not at the show (but they have it!) Lattice - Sorry I forgot about you guys, my fault, see you next time around! (I still have EC board on my wishlist of wanna have eval boards) Atmel - was there, hard to find, when found nothing to see nobody to talk, no espresso either. Antti PS All above are my personal and possible biased comments only, please read them light with :) on the face http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&rd=1&item=3852842807Article: 75734
"Ryan" <ryanclark410@hotmail.com> wrote in message news:sp6ld.116$ri7.3@newsfe5-win.ntli.net... > 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. Even if the design was originally done in an HDL, getting the original owner to release it will be next to impossible. However, recreating an older design in an HDL form doesn't take an unreasonable amount of time if the specifications are fairly complete (and accurate, see below). > 2) How can the exact EBI timings of the original be recreated (or how close > to the original is practical)? If you are talking nanoseconds, it's going to be time-consuming and probably not worth the effort as long as the timings are cycle-accurate. > 3) Cache memory cannot be recreated on-chip. And unless you have the time and inclination to figure out the internal timing for this kind of subsystem (a non-trivial task) you wil never be able to achieve cycle accuracy. A similar problem arises whenever you have more than one clock domain in the device, as the original synchronization strategy will be very difficult to discern. > 4) How close can the internal timings be recreated? It's actually an interesting exercise to try to figure out how the original design was implemented to come up with the original timings. I have done this twice, for the Z180 and the Z8000. I was able to match the Z180 clock cycle timing in all cases. The Z8000 was a different story, for two reasons. First, the exact timing for the case of the interrupt acknowledge was not specified except "1 to 7 clock cycles" for an aborted instruction fetch. Second, the published timing for both the multiply and divide instruction was clearly incorrect, as it did not account for the different addressing modes correctly, besides not making sense (from a clock cycle standpoint) relative to whether a bit in the divisor was set or not. > 5) Verification ?! If you write your testbench properly, and cover all the boundary cases, it's possible to exercise the original chip with the same stimulus and compare the results. This was very useful in my Z8000 case, where a number of instructions are described as having "undefined" flag values. I was able to figure out what the chip was doing in these "undefined cases" and match the behavior in my implementation. It's usually a case of figuring out where the original designer used "don't cares" in his logic design. This step is critical if you are working from a published spec. For example, the Z8000 divide instruction is completely specified, including boundary cases. This was obviously the work of the Z8000 architect, and is what I implemented. My testbench tested each of the specified boundary cases, only to find that the actual chip did not properly handle one boundary case! This was actually the hardest case to implement, and it seems that the designer decided to signal overflow rather than properly handle the case of the most-negative quotient (recall that the range of a 2's complement number is assymetric). Well, this change never made it into the published documentation for the chip. This "specification/implementation disconnect" is one of the more difficult aspects of this process. Without detailed and accurate specifications, the task can be impossible. I would add this to your list of important factors to consider. > > If anyone would like to contribute to this initial brainstorming, I'd be > grateful. There are a number of cases where this avenue is the most logical or even the least expensive. (Think about the cost requalifying flight-critical software, for example.) Emulating an older design on a fast new whiz-bang chip does nothing except postpone the problem, because what happens when that chip is obsolete in 18 months (or worse, in the middle of your redesign). Having the design in a retargetable HDL format makes the obsolesense problem manageable. Emulation is also grossly inefficient in terms of power, and can't hope to be hardware compatible except at the edges of the system, if then. > > Rupert. > >Article: 75735
I've just forgot to mention that I will use a PowerPC core.Article: 75736
>And unless you have the time and inclination to figure out the internal >timing for >this kind of subsystem (a non-trivial task) you wil never be able to achieve >cycle accuracy. A similar problem arises whenever you have more than one >clock domain in the device, as the original synchronization strategy will be >very >difficult to discern. Why not? Old cycle times were slow by modern standards. Just add enough delay to match the specs. -- 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: 75737
hmurray@suespammers.org (Hal Murray) 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? > Sure - you might be able to infer it, but you can also just instantiate it with the appropriate verilog of vhdl library component. The block ram's function as a fixed number of bits, which you can access with varying widths and lengths, and are optionally dual port. Do a directory of everything starting with RAMB in your xilinx/src/verilog/unisims directory to get an idea of the options. For example RAMB16_S9 is an 8bit+parity memory, and RAMB16_S9_S9 is the same thing in dual port configuration. One thing to remember is that this is SYNCHRONOUS memory - there's a clock delay in getting anything out of it. Initializing them as rom's is a bit of a pain, as you need to do it seperately for the simulation and for synthesis. For example, in verilog you would have: //synthesis translate_off defparam my_mem.INIT_00 = 256'h7B98606064C364C364C364C364C364C300006FC360646080F060607C64C30077; //synthesis translate_on To get the simulation values in there. For synthesis, you specify the value like this: //synthesis attribute init_00 of my_mem is "7B98606064C364C364C364C364C364C300006FC360646080F060607C64C30077" (synthesis directives are all formally verilog comments, hence the //) If you have processor code in the ROM, you can also use a .bmm file and the data2mem tool to let you change the code without recompiling the whole design. For example: my_mem.bmm: ADDRESS_BLOCK rom RAMB16 [0x00000000:0x00007FF] BUS_BLOCK my__mem3 [7:0] OUTPUT = my_dump.mem; END_BUS_BLOCK; END_ADDRESS_BLOCK; If you put my_mem.bmm in your project, XST will further process it and give you a my_mem_bd.bmm which you can then use along with a .mem file of data: data2bram -bm my_mem_bd.bmm -bt project.bit -bd my_mem.mem -o bv updated This will create an 'updated.bit' as well as an 'updated.v' with defparam's that you can `include (from within a //synthesis translate_off block!) in your design to subsequently have the same values in simulation. It's a pain to set up, but once it works it's really nice. ChrisArticle: 75738
Hi All, I need to implement a low pass digital filter on 12 bit ADC data in a Spatan IIE device, but I'd like it to be multiplier free - in other words just use adders and bit shifting for the coefficients. The sample rate is 12Mhz and I need a sharp cut-off at around 3MHz. Does anyone know of a simple design (IIR?) to do this, or a website/tutorial to give me some pointers? I've seen several websites with coefficient calculators, there are always a few coefficients that can't be easily calculated with bit shifting and adding. Thanks! Mark.Article: 75739
"markp" <map.nospam@f2s.com> wrote in message
news:2vn75sF2o7m4kU1@uni-berlin.de...
> Hi All,
>
> I need to implement a low pass digital filter on 12 bit ADC data in a
Spatan
> IIE device, but I'd like it to be multiplier free - in other words just
use
> adders and bit shifting for the coefficients. The sample rate is 12Mhz and
I
> need a sharp cut-off at around 3MHz. Does anyone know of a simple design
> (IIR?) to do this, or a website/tutorial to give me some pointers? I've
seen
> several websites with coefficient calculators, there are always a few
> coefficients that can't be easily calculated with bit shifting and adding.
>
> Thanks!
depending what you need, one solution is very simple "digital integrator"
its doable with only shift and add, there is some appnote or something at
xilinx web, I used that in digital carrier frequency amplifier, and it did
give actually very good filtering (for my application at least).
an example digital integrator source is appended
---------
--
-- 18 Bit Digital Integrator Feedback "multiplier"
-- constant 1 / 256 (fixed, no choices implemented)
-- Tested and working.
library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.STD_LOGIC_ARITH.ALL;
use IEEE.STD_LOGIC_UNSIGNED.ALL;
library work;
entity integrator_18bit is Port (
rst : in std_logic;
clk : in std_logic;
din : in std_logic_vector(17 downto 0); -- Input: 18 Bit Unsigned
INTEGER
k : in std_logic_vector(3 downto 0); -- multiplier select (not
implemented)
dout : out std_logic_vector(17 downto 0) -- Output: 18 Bit
Unsigned INTEGER
);
end integrator_18bit;
architecture Behavioral of integrator_18bit is
signal acc : std_logic_vector(25 downto 0);
signal vi_minus_vo : std_logic_vector(25 downto 0);
signal vi_minus_vo_sign_extended : std_logic_vector(7 downto 0);
begin
-- Microblaze "endian" conversion
dout(0) <= acc(25); dout(1) <= acc(24); dout(2) <= acc(23); dout(3) <=
acc(22);
dout(4) <= acc(21); dout(5) <= acc(20); dout(6) <= acc(19); dout(7) <=
acc(18);
dout(8) <= acc(17); dout(9) <= acc(16); dout(10) <= acc(15); dout(11)
<= acc(14);
dout(12) <= acc(13); dout(13) <= acc(12); dout(14) <= acc(11); dout(15)
<= acc(10);
dout(16) <= acc(9); dout(17) <= acc(8);
-- Error Value
vi_minus_vo <= (din & "00000000") - acc;
-- Sign Extension for Error Value
with vi_minus_vo(25) select vi_minus_vo_sign_extended(7 downto 0) <=
"00000000" when '0', "11111111" when others;
process (clk) begin
if (rst='1') then
acc <= "00000000000000000000000000";
else
if (clk'event and clk='1') then
-- Accumulate
acc <= acc + (vi_minus_vo_sign_extended(7 downto 0) & vi_minus_vo(25
downto 8));
end if;
end if;
end process;
end Behavioral;
Article: 75740On Sat, 13 Nov 2004 19:55:43 -0000, "markp" <map.nospam@f2s.com> wrote: >Hi All, > >I need to implement a low pass digital filter on 12 bit ADC data in a Spatan >IIE device, but I'd like it to be multiplier free - in other words just use >adders and bit shifting for the coefficients. The sample rate is 12Mhz and I >need a sharp cut-off at around 3MHz. Does anyone know of a simple design >(IIR?) to do this, or a website/tutorial to give me some pointers? I've seen >several websites with coefficient calculators, there are always a few >coefficients that can't be easily calculated with bit shifting and adding. > >Thanks! > >Mark. > See zipfile in abse. If I post it here, the formatting gets lunched. JohnArticle: 75741
"John Larkin" <jjlarkin@highlandSNIPtechTHISnologyPLEASE.com> wrote in message news:g0ucp0l3v5pmv3a8afvlil3g7b1k7u2jc1@4ax.com... > On Sat, 13 Nov 2004 19:55:43 -0000, "markp" <map.nospam@f2s.com> > wrote: > > >Hi All, > > > >I need to implement a low pass digital filter on 12 bit ADC data in a Spatan > >IIE device, but I'd like it to be multiplier free - in other words just use > >adders and bit shifting for the coefficients. The sample rate is 12Mhz and I > >need a sharp cut-off at around 3MHz. Does anyone know of a simple design > >(IIR?) to do this, or a website/tutorial to give me some pointers? I've seen > >several websites with coefficient calculators, there are always a few > >coefficients that can't be easily calculated with bit shifting and adding. > > > >Thanks! > > > >Mark. > > > > See zipfile in abse. If I post it here, the formatting gets lunched. Thanks John. Unfortunately I've got text only news server access, any chance in emailing? (remove .nospam). Cheers, Mark. > John >Article: 75742
On Sat, 13 Nov 2004 21:19:25 -0000, "markp" <map.nospam@f2s.com> wrote: > >"John Larkin" <jjlarkin@highlandSNIPtechTHISnologyPLEASE.com> wrote in >message news:g0ucp0l3v5pmv3a8afvlil3g7b1k7u2jc1@4ax.com... >> On Sat, 13 Nov 2004 19:55:43 -0000, "markp" <map.nospam@f2s.com> >> wrote: >> >> >Hi All, >> > >> >I need to implement a low pass digital filter on 12 bit ADC data in a >Spatan >> >IIE device, but I'd like it to be multiplier free - in other words just >use >> >adders and bit shifting for the coefficients. The sample rate is 12Mhz >and I >> >need a sharp cut-off at around 3MHz. Does anyone know of a simple design >> >(IIR?) to do this, or a website/tutorial to give me some pointers? I've >seen >> >several websites with coefficient calculators, there are always a few >> >coefficients that can't be easily calculated with bit shifting and >adding. >> > >> >Thanks! >> > >> >Mark. >> > >> >> See zipfile in abse. If I post it here, the formatting gets lunched. > >Thanks John. Unfortunately I've got text only news server access, any chance >in emailing? (remove .nospam). > >Cheers, > >Mark. >> John >> > OK, done, I think. JohnArticle: 75743
On Sat, 13 Nov 2004 13:10:15 -0800, John Larkin <jjlarkin@highlandSNIPtechTHISnologyPLEASE.com> wrote: >On Sat, 13 Nov 2004 19:55:43 -0000, "markp" <map.nospam@f2s.com> >wrote: > >>Hi All, >> >>I need to implement a low pass digital filter on 12 bit ADC data in a Spatan >>IIE device, but I'd like it to be multiplier free - in other words just use >>adders and bit shifting for the coefficients. The sample rate is 12Mhz and I >>need a sharp cut-off at around 3MHz. Does anyone know of a simple design >>(IIR?) to do this, or a website/tutorial to give me some pointers? I've seen >>several websites with coefficient calculators, there are always a few >>coefficients that can't be easily calculated with bit shifting and adding. >> >>Thanks! >> >>Mark. >> > >See zipfile in abse. If I post it here, the formatting gets lunched. > >John Oops, K1 should be 4, 1/16. File got scrambled somehow. JohnArticle: 75744
Monte Dalrymple wrote: > It's actually an interesting exercise to try to figure out how the > original design was > implemented to come up with the original timings. I have done this twice, > for the > Z180 and the Z8000. I was able to match the Z180 clock cycle timing in all > cases. The Z8000 was a different story, for two reasons. First, the exact > timing... Since you are an expert of Z8000, I'd like to ask you a question about Z8000, out of curiosity. I heard that Z8000 had bugs. Do you know what these bugs were, and whether they are corrected? Thank you. vax, 9000Article: 75745
Monte Dalrymple wrote: <snip> >>4) How close can the internal timings be recreated? > > > It's actually an interesting exercise to try to figure out how the original > design was implemented to come up with the original timings. I have done this twice, > for the Z180 and the Z8000. I was able to match the Z180 clock cycle timing in all > cases. The Z8000 was a different story, for two reasons. First, the exact > timing for the case of the interrupt acknowledge was not specified except "1 to 7 > clock cycles" for an aborted instruction fetch. Second, the published timing for > both the multiply and divide instruction was clearly incorrect, as it did not > account for the different addressing modes correctly, besides not making sense (from > a clock cycle standpoint) relative to whether a bit in the divisor was set or > not. <snip> Interesting, Sounds a lot of work on the Z8000, can you elaborate on the reasons/needs for this core, in particular. Could also be a good example, for the OP. -jgArticle: 75746
> I need to implement a low pass digital filter on 12 bit ADC data in a > Spatan > IIE device, but I'd like it to be multiplier free - in other words just > use > adders and bit shifting for the coefficients. The sample rate is 12Mhz and > I > need a sharp cut-off at around 3MHz. Does anyone know of a simple design > (IIR?) to do this, or a website/tutorial to give me some pointers? I've > seen > several websites with coefficient calculators, there are always a few > coefficients that can't be easily calculated with bit shifting and adding. Hi Mark, I can help you out with this by automatically generating VHDL for an FIR implementation for your filter that uses shifts and adds. Please post the following details: Do you want the filter to run at 12MHz (i.e. full-parallel) or do you have a faster clock available that could be used to share hardware over multiple clock cycles? Is the filter single-rate or are you decimating? Input bit-width? Signed/unsigned input? Quantised filter coefficients (integers ideally but fixed-point will do) or more detailed spectral requirements (what -dB gain at 3MHz, pass-band ripple etc., start rolling off at what freq, stop rolling of at what freq. etc.) Cheers, KenArticle: 75747
"Jim Granville" <no.spam@designtools.co.nz> wrote in message news:ytxld.1198$3U4.104987@news02.tsnz.net... > Monte Dalrymple wrote: > > <snip> > >>4) How close can the internal timings be recreated? > > > > > > It's actually an interesting exercise to try to figure out how the original > > design was implemented to come up with the original timings. I have done this twice, > > for the Z180 and the Z8000. I was able to match the Z180 clock cycle timing in all > > cases. The Z8000 was a different story, for two reasons. First, the exact > > timing for the case of the interrupt acknowledge was not specified except "1 to 7 > > clock cycles" for an aborted instruction fetch. Second, the published timing for > > both the multiply and divide instruction was clearly incorrect, as it did not > > account for the different addressing modes correctly, besides not making sense (from > > a clock cycle standpoint) relative to whether a bit in the divisor was set or > > not. > <snip> > > Interesting, Sounds a lot of work on the Z8000, can you elaborate on the > reasons/needs for this core, in particular. > Could also be a good example, for the OP. > > -jg > > The original customer for this design makes air data computers, and projects demand to continue well beyond when the "obsolete part stock" quantities of the Z8000 will be around. Since the software for this system has to be FAA certified, changing even one line of code is horrendously expensive. I'm sure that the OP was talking about exactly these kinds of applications. There are a number of similar applications out there, because the Z8000 was the first MIL-qualified 16-bit CPU and was designed into quite a few military and mil-spec systems. These are the kinds of systems with very long lifetimes. I know that the Z8000 was used in the F-15, the F-16, the 747 and the 757, for example. All of these aircraft are still flying and are still in production as far as I know. These kinds of applications are the exact opposite of the more common "throw-it-away-in-18 months" that most people deal with today. MonteArticle: 75748
"vax, 9000" <vax9000@gmail.com> wrote in message news:cn61r8$37l$1@charm.magnus.acs.ohio-state.edu... > Monte Dalrymple wrote: > > > It's actually an interesting exercise to try to figure out how the > > original design was > > implemented to come up with the original timings. I have done this twice, > > for the > > Z180 and the Z8000. I was able to match the Z180 clock cycle timing in all > > cases. The Z8000 was a different story, for two reasons. First, the exact > > timing... > > Since you are an expert of Z8000, I'd like to ask you a question about > Z8000, out of curiosity. I heard that Z8000 had bugs. Do you know what > these bugs were, and whether they are corrected? Thank you. > > vax, 9000 You can download the spec for my clone design at http://www.systemyde.com/pdf/y8002.pdf All of the differences between the published spec and what we found with the actual silicon are detailed there. I think that most of the bugs were back-annotated into the spec. For example, register R0 can't be used with some instructions, for no obvious reason. I think that some of the "undefined" flag settings were actually bugs that were deemed not important. The biggest one, in my opinion, had to do with divide not handling the one boundary case, as I mentioned in the previous post. And there is also the issue of cycle counts for both multiply and divide that can't be correct in the published spec. MonteArticle: 75749
"Alex Gibson" <al xx at tpg dot com dot au - remove spaces replace dot> wrote in message news:4195db13$0$31718$61c65585@un-2park-reader-01.sydney.pipenetworks.com.au... > > quite a few 6502 cores available Always read the small print though. Several 6502 cores have been published but most of them come with notes about not being completely finished. For example, BCD instructions missing. Daniel Wallner seems to be the only one who gets round to finishing stuff and testing it. > http://www.howell1964.freeserve.co.uk/logic/index_logic.htm lots of stuff Recently announced plans to clone Atari 800XL, which will be a bigger task than the Atom.
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