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
>yeah, if one has patience, one can derive each byte one by one. >I thought there must be some shortcut to this tideous process. Are you trying to understand how it works or looking for a simple recipe for getting the job done? I don't know of a simple recipe. I think there was a web site that may have generated VHDL/Verilog for CRCs. I forget. It was a long time ago. It might have done the parallel mode. The software guys often do CRC calculations a byte at a time rather than a bit at a time. You can probably find a lot of good info via google. Basically, it involves a table lookup. The length of the table is the size of your "byte". The width of the table is the width of the polynomial used to make your CRC. To do the normal CRC-32 (Ethernet) CRC a byte at a time takes a 256 entry table where each entry is 4 bytes wide. You can implement that table in hardware with a cloud of XOR gates. Some of the software routines compute the table at initialization time rather than pre-computing it and feeding a table of constants to the compiler. That tells you the cloud of gates that you need. (I think.) There are many ways to screwup CRC/scrambler calculations. The common ones are getting left/right mixed up. I strongly suggest checking things ahead of time with software/simulations. -- 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: 86326
c d saunter wrote: > Peter Alfke (alfke@sbcglobal.net) wrote: > : What's so great about a 30-year old CPU ? > : Peter Alfke > > 0x10 DJNZ > 0xD9 EXX > > The epitomie of CISC, but it illustrates very well why I like the z80 > instrucion set - it's simple enough to work in hardware that was around > before my time, but it represents a 'good fit' with the way my brain > works. > > --- > cds C9'ing 0x76 - enough already ! I have a complete ucLinux SoC running in an single FPGA (plus memory and a few PHYs). How can the Z80 beat that ? Don't get me wrong, I love the Z80, and used it a lot, but I think now it's time has passed ... Cheers, rudi ============================================================= Rudolf Usselmann, ASICS World Services, http://www.asics.ws Your Partner for IP Cores, Design, Verification and Synthesis ****** Certified USB 2.0 HS OTG and HS Device IP Cores ******Article: 86327
Jedi wrote: > Is it possible to have for each tool an own license file > path set? > > Lattice ispLever Base with synplify bites Actel Libero Platinum > with synplify since each version of synplify doesn't like > the other license file... > > > thx in advance > jedi I have been able to use the Actel OEM version of synplify with both the ispLEVER and Libero licenses enabled. However I have to disable the Libero synplify license when using the ispLever software with their OEM version of synplify. This has led me to believe the problem lies with the ispLEVER synplify licensing. I have now resulted to using synplify with Libero and Precision RTL synthesis with ispLEVER. Hope this helps BenArticle: 86328
Jedi wrote: > Hello.. > > Is this normal that same core which performs well > for Altera Cyclone device can only run at half speed > on a LFEC20-5 device? > > Tried with several CPU cores from opencores.org > and LAttice LFEC20 shows mostly half the performance > as Cyclone... > > > rick I cannot comment directly on your comparism as I have not performed the tests myself. As a comment however I would say that FPGA architectures are designed with certain characteristics in mind that may benefit certain coding styles and not the other. This is the reason why most FPGA vendors have a coding style guide to compliment their silicon. Without modifying off-the-shelf code to suit a particular FPGA it is very difficult to make a chalk and cheese comparism. The website I have discovered below has a comparism of opencore CPUs implemented on Altera Cyclone, Lattice ECP and Actel ProASIC 3 devices http://www.fpga.ch/ipcores/results.php Hope this helps BenArticle: 86329
Jedi wrote: >> c) At least you didn't confuse Sweden and Norway, you could be >> shot for that ;-) Right. I was in Norway twice and got an impression that most of the jokes were about Sweden :) > > ...so in this context it's better to make your homework right (o; Well, AFAIK Linus is from Finland but his first language is Swedish. Not that hard to get confused.Article: 86330
Peter Alfke wrote: > What's so great about a 30-year old CPU ? > Peter Alfke > I use the Acclaim ez80 to reconfigure my FPGA based boards over the ethernet. When you can achieve that with a CPU soft core running in an FPGA I would say that there is nothing great about a 30 year old CPU!! BenArticle: 86331
Jim Granville <no.spam@designtools.co.nz> wrote: ... > Imagine a stacked die FPGA, with a large VFast SRAM, and Config device ? You're dreaming :-) -- Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------Article: 86332
Austin Franklin wrote: > Hi JJ, > > >>Well I would say for their time the 8086, Z8000, 68k were all >>reasonably well crafted as VLSIs go... > > > Perhaps from a physical layout, but it was the architecture I was commenting > on. > > >>As for architecture Intel was only upgrading the 8080 to a 16bit arch, > > > In a terribly feeble way! There were some much better architectures > available (and do-able) at the time. > Hindsight is a wonderful thing. I suppose the questions are: What are these "better" and "do-able" architectures? Were they better then for the same reasons we consider them better now? Why don't you think they were adopted at that time? Are they more suited to implementation on today's FPGA technology? > >>Remarkably all these design teams had very little CAD available to them >>for most of the general designs... > > > I'm not sure I agree with that. I worked on a VLSI design system from > ComputerVision back in 1978... > Very little CAD is not the same as no CAD. There was CAD, it was just too expensive to be common place. > Regards, > > Austin > >Article: 86333
Hiya... I'm using Altera Quartus II, Pluto II (see fpga4fun.com, its one of their boards - GREAT site! - it's an Altera Cyclone), Verilog, you know the deal ;) I'm trying to integrate all my modules (for the purposes of this I have a compass module, which reads a direction over I2C, and a motor controller - PWM, reversible). These are held within a module called 'scanner'. Snippet'ed code in question: -----------------start of code-------------- input clk; input clk100khz; output hwSonarTrigger; input hwFrontEcho; input hwRearEcho; inout hwCompassSCL; inout hwCompassSDA; output hwSpinA; output hwSpinB; output [1:0] state; // for debugging purposes // ...snip... wire [7:0] compassDirection; wire compassDirectionUpdated; reg [7:0] spinSpeed; reg spinDirection; reg spinEnabled; // ...snip... reg [7:0] baseCompassDirection; wire [7:0] clockwiseDistance = baseCompassDirection - compassDirection; wire [1:0] antiClockwiseDistance = compassDirection - baseCompassDirection; reg [1:0] state = 0; // basic operation: // state 0 initialises, resets, forwards to state 1 // state 1 waits until a compass direction has been obtained, records the direction in baseCompassDirection, and moves into state 2 // state 2 compares the stored compass direction against the measured, and sets the motor controller to correct for movement always @(posedge clk) begin if ( state == 0 ) begin spinEnabled <= 0; spinSpeed <= 0; state <= 1; end else if ( state == 1 ) begin if ( compassDirectionUpdated == 1 ) begin baseCompassDirection <= compassDirection; spinSpeed <= 100; state <= 2; end end else if ( state == 2 ) begin spinEnabled = (clockwiseDistance != 0); if ( clockwiseDistance < antiClockwiseDistance ) spinDirection <= 1; else spinDirection <= 0; end end // ...snip... compass COMPASS(.clk(clk), .clk100khz(clk100khz), .compassSDA(hwCompassSDA), .compassSCL(hwCompassSCL), .direction(compassDirection), .directionUpdate(compassDirectionUpdated)); spinner SPINNER(.clk(clk), .speed(spinSpeed), .direction(spinDirection), .enabled(spinEnabled), .hwSpinA(hwSpinA), .hwSpinB(hwSpinB)); -----------------end of code-------------- The modules work fine individually, but here it just doesnt work. I get messages like: Warning: No clock transition on "scanner:SCANNER|baseCompassDirection[7]" register Warning: Reduced register "scanner:SCANNER|baseCompassDirection[7]" with stuck clock port to stuck value GND (repeated same from [7] down to [0]) .. Warning: Pin "state[1]" stuck at VCC Warning: Pin "state[0]" stuck at GND .. Info: Pin state[0] has GND driving its datain port Info: Pin state[1] has VCC driving its datain port The Altera simulation (20ms long) shows the thing is only ever in state 2 - these seems to be in keeping with the 'state pins stuck' messages. The compass is queried, other than that not alot of activity happens. But why? And what's the cause of my baseCompassDirection register messages? What about the way the state is always 2? Anyone have any ideas? I would be eternally grateful - it's quite a frustrating learning process at the moment. I'm a software developer by profession so perhaps I'm just approaching it wrong. Cheers, kierenj (side note: the 'spinner' module is a simple motor controller - drives a h-bridge ;), has a direction 0/1 and speed 0..255, achieved using PWM. the 'compass' module continually queries an I2C bus for compass reading, updating its direction output and pulsing directionUpdated as it does so.)Article: 86334
Hi Ben, > The website I have discovered below has a comparism of opencore CPUs > implemented on Altera Cyclone, Lattice ECP and Actel ProASIC 3 devices > > http://www.fpga.ch/ipcores/results.php Nice results (speaking as an Altera guy :-)). I don't agree with the author's hypothesis that Synplify is the difference -- if Synplify were used for Cyclone as well, I don't think the conclusion would change. Synplify is a great synthesis tool. And the results should get even better if some or all of the various physical synthesis options were enabled in Quartus II. Neat link -- thanks. Paul Leventis Altera Corp.Article: 86335
fpgaguy@aedinc.net wrote: > Bo wrote: > > For what it's worth..we were told by visiting Xilinx engineer to NOT upgrade > > our tools to 7.x but instead wait for 8.1 release in August... > > I was told the same thing. We ran into a problem with timing driven > map in 7.1 which made our design impossible to implement. 6.3 works > well. They have it fixed in 8.1 (it implemented nicely with 8.1) but > it won't be fixed in 7.1 sp3. We were told to skip 7.1 unless we need > it for S3E or possibly V4. Looks like I spoke too soon. We also have a design that won't implement in 7.1i (it's very full), but does fine with 6.3i. So maybe my original response to the OP should have been something closer to "7.1i works fine for all but a few things. If you run into those, you'll need to drop back to 6.3i." MarcArticle: 86336
Hi, I want to know if there is a method of loading/updating firmware into an SPROM using the network. Rather than physically replacing the SPROM in the field, we want to transmit it over the network program the SPROM using the JTAG interface or other. What method can be used to program it remotely? Can it be made secure? Thanks AndrewArticle: 86337
kierenj@handtheband.com wrote:
> These are held within a module called 'scanner'.
>
> Snippet'ed code in question:
>
> -----------------start of code--------------
>
> input clk;
Hmm, you left out the module declaration -- at least I hope you have one!
> reg [1:0] state = 0;
>
> // basic operation:
> // state 0 initialises, resets, forwards to state 1
> // state 1 waits until a compass direction has been obtained, records
> the direction in baseCompassDirection, and moves into state 2
> // state 2 compares the stored compass direction against the measured,
> and sets the motor controller to correct for movement
And then what? You never transistion out of state 2, is that
intentional? Shouldn't you at least go back to state 1 every once in a
while?
Suggestions:
- Show us *all* the code as often the bugs are not in what's posted
- Use parameter INIT = 0; etc and give the states symbolic names
- Use a case statement instead
case state
INIT: begin ...
endcase
- Keep the names the same inside and outside the module. That lessens
confusion and the change of mispelling (which btw is silently assumed to
be an implicitly declared net).
Cheers,
Tommy
>
> always @(posedge clk) begin
> if ( state == 0 ) begin
> spinEnabled <= 0;
> spinSpeed <= 0;
> state <= 1;
> end else if ( state == 1 ) begin
> if ( compassDirectionUpdated == 1 ) begin
> baseCompassDirection <= compassDirection;
> spinSpeed <= 100;
> state <= 2;
> end
> end else if ( state == 2 ) begin
> spinEnabled = (clockwiseDistance != 0);
> if ( clockwiseDistance < antiClockwiseDistance )
> spinDirection <= 1;
> else
> spinDirection <= 0;
> end
> end
>
> // ...snip...
>
> compass COMPASS(.clk(clk), .clk100khz(clk100khz),
> .compassSDA(hwCompassSDA), .compassSCL(hwCompassSCL),
> .direction(compassDirection),
> .directionUpdate(compassDirectionUpdated));
> spinner SPINNER(.clk(clk), .speed(spinSpeed),
> .direction(spinDirection), .enabled(spinEnabled), .hwSpinA(hwSpinA),
> .hwSpinB(hwSpinB));
>
> -----------------end of code--------------
>
> The modules work fine individually, but here it just doesnt work. I
> get messages like:
>
> Warning: No clock transition on
> "scanner:SCANNER|baseCompassDirection[7]" register
> Warning: Reduced register "scanner:SCANNER|baseCompassDirection[7]"
> with stuck clock port to stuck value GND
> (repeated same from [7] down to [0])
> ..
> Warning: Pin "state[1]" stuck at VCC
> Warning: Pin "state[0]" stuck at GND
> ..
> Info: Pin state[0] has GND driving its datain port
> Info: Pin state[1] has VCC driving its datain port
>
> The Altera simulation (20ms long) shows the thing is only ever in state
> 2 - these seems to be in keeping with the 'state pins stuck' messages.
> The compass is queried, other than that not alot of activity happens.
> But why? And what's the cause of my baseCompassDirection register
> messages? What about the way the state is always 2?
>
> Anyone have any ideas? I would be eternally grateful - it's quite a
> frustrating learning process at the moment. I'm a software developer
> by profession so perhaps I'm just approaching it wrong.
>
> Cheers,
> kierenj
>
>
>
> (side note: the 'spinner' module is a simple motor controller - drives
> a h-bridge ;), has a direction 0/1 and speed 0..255, achieved using
> PWM. the 'compass' module continually queries an I2C bus for compass
> reading, updating its direction output and pulsing directionUpdated as
> it does so.)
>
Article: 86338"Andrew Lohbihler" <andrewl@rogers.com> schrieb im Newsbeitrag news:dqKdnRJODdW_GyDfRVn-oA@rogers.com... > Hi, I want to know if there is a method of loading/updating firmware into an > SPROM using the network. Rather than physically replacing the SPROM in > the field, we want to transmit it over the network program the SPROM > using the JTAG interface or other. What method can be used to program it > remotely? Can it be made secure? > > Thanks > Andrew > yes it is possible, but you need a separate microcontroller to be in charge of the of the configuration update process. Rewriting the sprom would be possible also from the softcore CPU that is loaded from the sprom, but any such method would never be completly fail safe. Also you need a sprom to be able to hold 2 complet biststreams at least. Rather than using configuration prom it would be easier to use normal serial prom and let the configuration microcontroller to handle the configuration, if that is applicable. depends on the speed requirements of the configuration process www.hydraxc.com is a product that can potentially do completly fail-safe network update of the configuration. the module has a small flash micrcontroller that is capable to load the fpga from on board ST serial flash at 4mbit/sec. The flash can contain several configurations. as long as on bitstream is the dedicated fail-safe update bitstream the updates are completly safe and the update will never come to deadlock as all cases where error happened during download or update the configuration controller will trap that and use the fail-safe bitstream. AnttiArticle: 86339
"Piotr Wyderski" <wyderskiREMOVE@ii.uni.wroc.pl> skrev i meddelandet news:d990fp$a3g$1@news.dialog.net.pl... > Adam Megacz wrote: > >> Hey, does anybody know if you can damage Atmel's newer FPGAs with a >> bad bitstream (ie vdd-to-ground contention)? > > The same question: is it possible to damage a Cyclone with a bad > bitstream? > Remark: it's a feature, not a bug. SRAM-based FPGA devices are too easy > to clone. FPGA manufacturers: why can't you mount two chips inside one > package, > one containing an FPGA and the second one with configuration flash and add > readback fuses, JTAG access fuses etc.? A small amount of EEPROM would > be great too... > > Best regards > Piotr Wyderski > AT94Sxx Secure FPSLIC? -- A. P. RichelieuArticle: 86340
Hi, I need to interface 2 ADCs and 1 DAC to a Spartan-II FPGA running at 57.6MHz. My data (12-bits wide) needs to be sampled at 200kHz and to save pins I'm going to be using serial ADCs/DACs. As I understand it, using the SPI protocol I would need to read/write 16-bit words at 200kHz needing 3.2Msps converters. From what I've read about SPI, all slave devices connected to the same master have to share the same I/O bus and have separate CS pins. - What I can't understand is, if I need my 2 ADCs and 1 DAC to communicate with the FPGA simultaneously, how do I achieve this when they have to share the same bus? - Are there application notes I could refer to for guidance (I haven't been able to locate any by googling)? - Would I need separate serial clocks (SCLK) for each converter and can I generate the SCLK using counters, so for instance to get a 3.2MHz SCLK period, count 18 clock cyles in the 57.6MHz domain of the FPGA system clock? -Do I have to feed SCLK into a clock output pin or a will a general I/O pin do? thanks, MeesArticle: 86341
Paul Leventis (at home) wrote: > Hi Ben, > > >>The website I have discovered below has a comparism of opencore CPUs >>implemented on Altera Cyclone, Lattice ECP and Actel ProASIC 3 devices >> >>http://www.fpga.ch/ipcores/results.php > > > Nice results (speaking as an Altera guy :-)). I don't agree with the > author's hypothesis that Synplify is the difference -- if Synplify were used > for Cyclone as well, I don't think the conclusion would change. Synplify is > a great synthesis tool. > > And the results should get even better if some or all of the various > physical synthesis options were enabled in Quartus II. > > Neat link -- thanks. > > Paul Leventis > Altera Corp. > > The lattice ispLever tool comes with 3 different synthesis tools: Leonardo Spectrum, Synplify and Precision RTL synthesis. Using Synplify and Precision RTL synthesis on the same VHDL code without applying rigorous timing constraints shows a significant increase in fmax in favour of the RTL synthesis tool. So perhaps the author has a point.Article: 86342
m_oylulan@hotmail.com wrote: > Hi, > > I need to interface 2 ADCs and 1 DAC to a Spartan-II FPGA running at > 57.6MHz. My data (12-bits wide) needs to be sampled at 200kHz and to > save pins I'm going to be using serial ADCs/DACs. > > As I understand it, using the SPI protocol I would need to read/write > 16-bit words at 200kHz needing 3.2Msps converters. From what I've read > about SPI, all slave devices connected to the same master have to share > the same I/O bus and have separate CS pins. > > - What I can't understand is, if I need my 2 ADCs and 1 DAC to > communicate with the FPGA simultaneously, how do I achieve this when > they have to share the same bus? > > - Are there application notes I could refer to for guidance (I haven't > been able to locate any by googling)? > > - Would I need separate serial clocks (SCLK) for each converter and can > I generate the SCLK using counters, so for instance to get a 3.2MHz > SCLK period, count 18 clock cyles in the 57.6MHz domain of the FPGA > system clock? > > -Do I have to feed SCLK into a clock output pin or a will a general I/O > pin do? > > thanks, > Mees > What is preventing you from having multiple SPI cores?Article: 86343
bijoy wrote:
>Hi
>
>Any body used FFT core given by coregenerator in Xilinx ?
>
>Does it work as they said in their data sheet..
>
>regards bijoy
>
>
It works. You get what you pay for, though. There are other cores
available that are faster and denser, but alas, they are not free.
--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com
"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
Article: 86344
What do you mean by "not implement"? Does it not close timing, not fit in
the chip, not route or not create correct logic? Are there any bugs
specifically for very full Virtex-IIs?
In article <1119714524.207809.146560@o13g2000cwo.googlegroups.com>,
Marc Randolph <mrand@my-deja.com> wrote:
>
>
>fpgaguy@aedinc.net wrote:
>> Bo wrote:
>> > For what it's worth..we were told by visiting Xilinx engineer to NOT upgrade
>> > our tools to 7.x but instead wait for 8.1 release in August...
>>
>> I was told the same thing. We ran into a problem with timing driven
>> map in 7.1 which made our design impossible to implement. 6.3 works
>> well. They have it fixed in 8.1 (it implemented nicely with 8.1) but
>> it won't be fixed in 7.1 sp3. We were told to skip 7.1 unless we need
>> it for S3E or possibly V4.
>
>Looks like I spoke too soon. We also have a design that won't
>implement in 7.1i (it's very full), but does fine with 6.3i.
>
>So maybe my original response to the OP should have been something
>closer to "7.1i works fine for all but a few things. If you run into
>those, you'll need to drop back to 6.3i."
>
> Marc
>
--
/* jhallen@world.std.com (192.74.137.5) */ /* Joseph H. Allen */
int a[1817];main(z,p,q,r){for(p=80;q+p-80;p-=2*a[p])for(z=9;z--;)q=3&(r=time(0)
+r*57)/7,q=q?q-1?q-2?1-p%79?-1:0:p%79-77?1:0:p<1659?79:0:p>158?-79:0,q?!a[p+q*2
]?a[p+=a[p+=q]=q]=q:0:0;for(;q++-1817;)printf(q%79?"%c":"%c\n"," #"[!a[q-1]]);}
Article: 86345>I need to interface 2 ADCs and 1 DAC to a Spartan-II FPGA running at >57.6MHz. My data (12-bits wide) needs to be sampled at 200kHz and to >save pins I'm going to be using serial ADCs/DACs. > >As I understand it, using the SPI protocol I would need to read/write >16-bit words at 200kHz needing 3.2Msps converters. From what I've read >about SPI, all slave devices connected to the same master have to share >the same I/O bus and have separate CS pins. I don't follow what you are trying to say. "3.2Msps" looks like 3.2 mega samples per second yet your previous paragraph says "sampled at 200kHz". SPI is a bit serial protocol. You will have to clock it fast enough to get all your data bits in one sample time. The converters don't sample any faster than your target sample rate - just the clock for the serial data path. If you are using sigma-delta type converters, they may also use the serial clock to run some digital logic. I suggest reading the data sheet for the converters you are considering. They should have timing diagrams. -- 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: 86346
> In article <1119714524.207809.146560@o13g2000cwo.googlegroups.com>, > Marc Randolph <mrand@my-deja.com> wrote: > >fpgaguy@aedinc.net wrote: > >> > >> I was told the same thing. We ran into a problem with timing driven > >> map in 7.1 which made our design impossible to implement. 6.3 works > >> well. They have it fixed in 8.1 (it implemented nicely with 8.1) but > >> it won't be fixed in 7.1 sp3. We were told to skip 7.1 unless we need > >> it for S3E or possibly V4. > > > >Looks like I spoke too soon. We also have a design that won't > >implement in 7.1i (it's very full), but does fine with 6.3i. > > > >So maybe my original response to the OP should have been something > >closer to "7.1i works fine for all but a few things. If you run into > >those, you'll need to drop back to 6.3i." > > What do you mean by "not implement"? Does it not close timing, not fit in > the chip, not route or not create correct logic? Are there any bugs > specifically for very full Virtex-IIs? Wouldn't fit/route (depending on timing based MAP mode) with 7.1i. 6.3i shows 91% LUTs used in an LX25, and runs through the tools in under an hour while meeting timing (50/50 split between 77 and 155 MHz). I've not noticed any difference between using the V4 global optimization step and not (except that it increase run times by a huge amount) - has anyone else? I have not heard anything, one way or the other, about V2 designs with 7.1i. I will say that if your design is really very full and you are happy with your results in 6.3i, I wouldn't really expect better results with 7.1i. It may (or may not) run through MAP and PAR a bit faster, but I've not see it mapping any more efficiently on two V4 designs. Marc P.S. It's exceedingly rare to have incorrect logic created - I can't remember the last time I've heard of that.Article: 86347
Hi there, Originally I didnt include all the code since there are several modules, and lots of lines in them. I've changed the state machine to use a case statement and symbolic names. (Yes, it is intentional, after the initial power-up reading I'd like it to go through the states 0, 1, and stay at 2). The full source is attached below. //////////////////////////////////////////////// module scanner(clk, clk100khz, hwCompassSCL, hwCompassSDA, hwSpinA, hwSpinB, state); //////////////////////////////////////////////// // SECTION: Inputs / Outputs //////////////////////////////////////////////// input clk; input clk100khz; inout hwCompassSCL; inout hwCompassSDA; output hwSpinA; output hwSpinB; output [1:0] state; //////////////////////////////////////////////// wire [7:0] compassDirection; wire compassDirectionUpdated; reg [7:0] spinSpeed; reg spinDirection; reg spinEnabled; //////////////////////////////////////////////// reg [7:0] baseCompassDirection; wire [7:0] clockwiseDistance = baseCompassDirection - compassDirection; wire [1:0] antiClockwiseDistance = compassDirection - baseCompassDirection; reg [1:0] state = 0; //////////////////////////////////////////////// parameter INIT = 0; parameter ACQUIRE = 1; parameter MONITOR = 2; //////////////////////////////////////////////// always @(posedge clk) begin case ( state ) INIT: begin spinEnabled <= 0; spinSpeed <= 0; state <= ACQUIRE; end ACQUIRE:begin if ( compassDirectionUpdated == 1 ) begin baseCompassDirection <= compassDirection; spinSpeed <= 100; state <= MONITOR; end end MONITOR:begin spinEnabled <= (clockwiseDistance != 0); if ( clockwiseDistance < antiClockwiseDistance ) spinDirection <= 1; else spinDirection <= 0; end endcase end //////////////////////////////////////////////// compass COMPASS(.clk(clk), .clk100khz(clk100khz), .compassSDA(hwCompassSDA), .compassSCL(hwCompassSCL), .direction(compassDirection), .directionUpdate(compassDirectionUpdated)); spinner SPINNER(.clk(clk), .speed(spinSpeed), .direction(spinDirection), .enabled(spinEnabled), .hwSpinA(hwSpinA), .hwSpinB(hwSpinB)); //////////////////////////////////////////////// endmodule //////////////////////////////////////////////// State is still stuck at 2 (MONITOR) and baseCompassDirection is apparently tied to GND (as the errors stated before). I can link to the source for compass / spinner if required, too? Thanks againArticle: 86348
news://news.openchip.org anttiArticle: 86349
Hello, thanks for your responses. I am sorry.I guess I hadn't understood that you could have multiple SPI interfaces. The wording of what I've read and the diagrams indicate separate CS lines for each slave but appeared to imply that all the slaves were sharing the same MOSI, and MISO buses. My mistake. I also see where I've gone wrong with the converter specification. I was confusing the converter throughput with the desired SCLK speed. The converters only need to have a bit sample rate of 200kHz, and then SCLK needs to be 3.2MHz in order to shift/sample the bits through. Thanks again, Mees
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