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'm designing another FSM and I've run into the problem I always have
when trying to pipeline them for high-speed designs. I'll show a simple
example.
STATE2: begin
if (condition)
begin
state <= STATE3;
y <= a*b+c;
end
end
The problem occurs if I need to add pipelining to meet speed
requirements: in this case, the multiplier inputs, output, and adder
output must be registered. So I have to end up doing this in the FSM:
STATE2: begin
if (condition)
begin
state <= STATE3;
a_pipe <= a;
b_pipe <= b;
end
end
and outside the FSM I have to have concurrent FSMs or other logic:
always@(posedge clk)
begin
m <= a_pipe * b_pipe;
p <= m + c;
y <= p;
end
The whole simplicity of the FSM is destroyed. Debugging and maintaining
it becomes very difficult. The output y isn't available for three
cycles, so I have to figure out what states the FSM might be in at that
point and ensure that I don't use y before it's ready. Using any sort
of FSM editor (like those bubble diagram schematic editors) is
completely precluded. A similar problem crops up when 'condition' is a
complex equation and has to be pipelined into the past. A common
example if 'condition' has a comparison that doesn't meet timing:
if (stuff && wide_counter==32'b3) ...
If this doesn't meet timing, I can instead pipeline the condition
outside the FSM:
wide_counter_eq_3 <= wide_counter==32'b2; // will be 3 on next cycle
and then inside the FSM:
if (stuff && wide_counter_eq_3) ...
but this can get messy and get screwed up if the counter doesn't always
increment from 2 to 3.
My question: what is the cleanest way to describe an FSM requiring
pipelining? Is there some sort of tool that will let me make a nice
bubble diagram but also indicate which operations need pipelined and
will then generate the proper synthesizable HDL?
-Kevin
Article: 131701Thanks G=F6ran, that's very impressive. You are right about the double precision, and output. With the below patch applied, I now clock in at 42.5 s. Could you try it again (I assume your numbers were with floats). Using local memory however doesn't make for an apples to apples comparison as this benchmark is memory heavy and local memory (as opposed to cache + slow memory) will give MB a large advantage. Thanks Tommy PS: Which FPGA was this on? On Apr 29, 5:31 am, "G=F6ran Bilski" <goran.bil...@xilinx.com> wrote: > Hi, > > Actually the use of floating-point at all seems unnecessary in the program= . > Think this is a legacy of PC program where the usage of double (or float) = is > not performance critical as on CPU without a FPU. > > I think it's safe to change to double in the program to int without any > changes in result. > The program would not run faster on a MAC/PC with this change but it will > have a drastic effect on your CPU. > > G=F6ran > > "G=F6ran Bilski" <goran.bil...@xilinx.com> wrote in message > > news:fv70te$7s01@cnn.xsj.xilinx.com... > > > Hi, > > > I did a quick test with MicroBlaze. > > With 125 MHz and 64kbyte of local memory, it takes MicroBlaze 6.8s to r= un > > the benchmark. > > > I added two defines in the program. > > #define printf xil_printf > > #define double float > > The first define is to get a smaller code footprint since the default > > printf is bloated and no floating-point is printed. > > The second define will make the compiler to use the MicroBlaze FPU > > single-precision floating-point compare and conversion instructions. > > Neither defines will change the program result since there is no actual > > floating-point calculations, just compare and conversions. > > > Actually the program prints out a relative large number of characters an= d > > if I remove the printf statement that is part of the loop, the program > > executes in 6.1 s > > The baudrate will have an effect on the execution speed if too many prin= ts > > exists in the timed section. > > > G=F6ran > > > "Tommy Thorn" <tommy.th...@gmail.com> wrote in message > >news:f005305a-30b9-4ca2-ae01-7fd3e2622853@l17g2000pri.googlegroups.com...= > >>I trying to get a feel for how the performance of my (so far > >> unoptimized) soft-core stacks up against the established competition, > >> so it would be a great help if people with convenient access to Nios > >> II / MicroBlaze respectively would compile and time this little app: > >>http://radagast.se/othello/endgame.c(It's an Othello endgame solver. > >> I didn't write it) and tell me the configuration. > > >> In case anyone cares, mine finished this in 100 seconds in this > >> configuration: 8 KiB I$, 16 KiB D$, 48 MHz clock frequency, async > >> sram. (My Mac finished this in ~ 0.5 sec :-) > > >> Thanks > >> TommyArticle: 131702
Forgot the patch. I'm sure Google Groups will mangle it for me.
Tommy
diff --git a/testcases/demos/smith-weill-gunnar-endgame.c b/testcases/
demos/smith-weill-gunnar-endgame.c
index 55f02d5..55a92db 100644
--- a/testcases/demos/smith-weill-gunnar-endgame.c
+++ b/testcases/demos/smith-weill-gunnar-endgame.c
@@ -168,2 +168,4 @@ additional 1.5 or so.
+#define double long
+
/* #define WINDOWS_TIMING */
@@ -989,3 +991,3 @@ int main( void ){
}
- printf("%3d (emp=%2d wc=%2d bc=%2d) %s\n",
+ if (0) printf("%3d (emp=%2d wc=%2d bc=%2d) %s\n",
val, emp,wc,bc, bds[i] );
Article: 131703RealInfo wrote: > Really ?? Really.Article: 131704
Kevin Neilson wrote:
> My question: what is the cleanest way to describe an FSM requiring
> pipelining?
I don't know, but I use a step counter
and a case of that step counter in
a synchronous block.
-- Mike Treseler
Article: 131705"austin" <austin@xilinx.com> wrote in message news:fv7bts$6iv3@cnn.xsj.xilinx.com... > > The data sheet is clear. > Sorry Austin, but it is ABSOLUTELY not. The table 4 of the datasheet says that Iccintq is typically 139 mA for the particular part we've been discussing. The note 6 to that table is saying to "Use the XPower Estimator (XPE) tool to calculate maximum static power for specific process, voltage, and temperature conditions." Now, the Power-On Power Supply Requirements chapter says that "Xilinx® FPGAs require a certain amount of supply current during power-on to insure proper device initialization. The actual current consumed depends on the power-on ramp rate of the power supply." It doesn't say anything about how it depends on the power-on ramp however. Now, on the top of all this you are saying that the Iccintmin number from table 5 is the real Iccintq, and not the one given in table 4 or reported by the power estimator. I can't agree that this is clear by any means. /MikhailArticle: 131706
On 29 Apr., 00:05, austin <aus...@xilinx.com> wrote: > mowa, > > The first, and most obvious difference, is that an unencrypted bitstream > is mostly all 0's. There are less than 10% of the bits that are set to > 1's in a bitstream. > > Identifying the structure of the bitstream is not all that tough: 1312 > bit frames in V4 and V5, 41 frames for a column of CLB's, locations of > BRAM data, etc. For example, place all BRAMs in a design with initial > values of 0xAAh, and then the 10101010 binary patterns will pop out for > the BRAM blocks. When encrypted, there will never be a block of > 10101010 the length of a BRAM any longer (as it will have been encrypted) > > The second, and fairly obvious difference, is that encryption tends to > make things look like noise, so an encrypted bitstream has ~ 50% 1's > and 50% 0's (looks like a random string of 1's and 0's). Nothing in the > bitstream will "make any sense" or correlate with anything that you > think it should be (i.e BRAM contents as above). > > To prove to yourself that the encryption which is performed is AES256 > per the NIST standard, one has to read how we format the bistream: what > comes before the encrypted part, and what follows after the encryption > ends and then to decrypt that middle part using a NIST c or Fortran > program with the key you used to encrypt with. > > The AES256 encryption has been confirmed by more than one third party, > so depending on how paranoid you are, you may or may not want to > duplicate this work (although it is not hard to do, just takes some > programming skills). > > Austin Austin it takes a) some programming skills b) re-inventing SOME missing info from Xilinx I assume this is what the OP/others have been trying to tell you. Some bitstream info is documented yes. Some not, I have not looked the very last documents but a while ago it was not so easy to implement the auto-crc on some devices (based solely on Xilinx info) my bet is that is the same with the AES256 as well As example is it plain normal CBC or not? WHERE is that information? Sure it is easy to verify that there is encryption by looking ad 01 density, but some want to check more than that AnttiArticle: 131707
On 25 Apr., 15:45, "u_stad...@yahoo.de" <u_stad...@yahoo.de> wrote: > hi > > Thanks for the link. Well the problem is the this is a university > project and I'm stuck with what they gave me which is the hydraXC > module on the eval board and a zip file containing the HydraXC user > manual and something that looks like a sample project. > Within the zip file in that sample project there is a folder with 2 > files: top.bit and image.bin. > What I did first was i formatted the sd card to fat 16 and then copied > the 2 file on it. Inserted the sd card into the hydra and powered on. > but nothing happens. shouldn't I see some output on the serial > interface? > > When I generate a bitstream with EDK I follow the same procedure > right? Copy onti the sd card and power on? > > Btw: I followed your link but either I'm blind or the site does not > contain any manuals or sample projects. > > thanks > urban Hi, I did give the current official link to the manufacturers website. But as of "unofficial" informtion the all hydraXC project/product range is officially dead already more then 6 months ago. My guess one reason for this is also the fact that the supplier never made the documents available online. You should try asking for the "support DVD" that includes EDK projects etc. try simple things: 1) make LED ON bitfile, that you can test it is loaded ok. select JTAG as startup clock !!!! 2) format miniSD FAT16 3) copy download.bit to sd card check the LEDs AnttiArticle: 131708
Hello,
I currently working on a project in EDK 9.1.
I have a PPC system with a custom peripheral the is connected to the
PPC through FSL->FCB->APU.
If I create an EDK project using microblaze and integrate my
peripheral I can read an write to my peripheral and all the data it
computes is correct.
Using the same peripheral (integrate my custom peripheral with the
coprocessor wizard) in an EDK project that uses PPC I run in some
problems:
( To clarify I developed the drivers for my custom peripheral using
the driver templates generated by the "create peripheral wizard")
When i create a stand alone application and use the drivers is have
to include a "usleep(1);" after every read or write
( fslput() or fslget() )to the bus. otherwise the data on the bus is
sometimes corrupt.
But when I create a software project that uses Xilkernel my peripheral
doesn't work anymore. It looks somehow that the data written to and
read from is is always corrupted even with the wait cycles...
does anyone have a hint for me?
I found some older post about the apu and fsl here (http://
groups.google.at/group/comp.arch.fpga/browse_thread/thread/
416bd68f00233500/b2bb54d16112f204?lnk=st&q=APU+MSR
+FSL#b2bb54d16112f204)
but unfortunately I don't know about what patch they are talking
about.
The code I use to initialize the apu is:
unsigned int msr_data;
msr_data = mfmsr();
msr_data = msr_data | XREG_MSR_APU_AVAILABLE | XREG_MSR_APU_ENABLE;
mtmsr(msr_data);
.........
xilkernel_main();
BTW: I found in the XIlinx data sheets that these bit should be set to
0 because they are not supported?? whats that all about? I found this
piece of code in another sample project an for the standalone PPC
project this works. Do I have to use another initialization for the
xilkernel?
Thanks Urban
Article: 131709On 29 Apr., 20:12, Antti <Antti.Luk...@googlemail.com> wrote: > On 25 Apr., 15:45, "u_stad...@yahoo.de" <u_stad...@yahoo.de> wrote: > > > > > > > > > hi > > > Thanks for the link. Well the problem is the this is a university > > project and I'm stuck with what they gave me which is the hydraXC > > module on the eval board and a zip file containing the HydraXC user > > manual and something that looks like a sample project. > > Within the zip file in that sample project there is a folder with 2 > > files: top.bit and image.bin. > > What I did first was i formatted the sd card to fat 16 and then copied > > the 2 file on it. Inserted the sd card into the hydra and powered on. > > but nothing happens. shouldn't I see some output on the serial > > interface? > > > When I generate a bitstream with EDK I follow the same procedure > > right? Copy onti the sd card and power on? > > > Btw: I followed your link but either I'm blind or the site does not > > contain any manuals or sample projects. > > > thanks > > urban > > Hi, > > I did give the current official link to the manufacturers website. > > But as of "unofficial" informtion the all hydraXC project/product > range is officially dead already more then 6 months ago. > My guess one reason for this is also the fact that the supplier never > made the documents available online. > > You should try asking for the "support DVD" that includes EDK projects > etc. > > try simple things: > 1) make LED ON bitfile, that you can test it is loaded ok. select JTAG > as startup clock !!!! > 2) format miniSD FAT16 > 3) copy download.bit to sd card > > check the LEDs > > Antti thank you!! already found the problem: rs232 connector was loose and therefore I did not see anything...Article: 131710
On 29 Apr., 20:42, "u_stad...@yahoo.de" <u_stad...@yahoo.de> wrote: > On 29 Apr., 20:12, Antti <Antti.Luk...@googlemail.com> wrote: > > > > > On 25 Apr., 15:45, "u_stad...@yahoo.de" <u_stad...@yahoo.de> wrote: > > > > hi > > > > Thanks for the link. Well the problem is the this is a university > > > project and I'm stuck with what they gave me which is the hydraXC > > > module on the eval board and a zip file containing the HydraXC user > > > manual and something that looks like a sample project. > > > Within the zip file in that sample project there is a folder with 2 > > > files: top.bit and image.bin. > > > What I did first was i formatted the sd card to fat 16 and then copied > > > the 2 file on it. Inserted the sd card into the hydra and powered on. > > > but nothing happens. shouldn't I see some output on the serial > > > interface? > > > > When I generate a bitstream with EDK I follow the same procedure > > > right? Copy onti the sd card and power on? > > > > Btw: I followed your link but either I'm blind or the site does not > > > contain any manuals or sample projects. > > > > thanks > > > urban > > > Hi, > > > I did give the current official link to the manufacturers website. > > > But as of "unofficial" informtion the all hydraXC project/product > > range is officially dead already more then 6 months ago. > > My guess one reason for this is also the fact that the supplier never > > made the documents available online. > > > You should try asking for the "support DVD" that includes EDK projects > > etc. > > > try simple things: > > 1) make LED ON bitfile, that you can test it is loaded ok. select JTAG > > as startup clock !!!! > > 2) format miniSD FAT16 > > 3) copy download.bit to sd card > > > check the LEDs > > > Antti > > thank you!! > already found the problem: > rs232 connector was loose and therefore I did not see anything... :) yes connectors are very often the problem AnttiArticle: 131711
I have a systemACE based dev. platform for Virtex-5 and copy my ace files by hand from my linux system to my CF card. Everything works fine with the auto-generated xilinx.sys file and the ace file. It also works with just the ace file in the root of the CF card. However, if I try to have multiple designs in a collection and hand-edit the xilinx.sys to point to each of them I just get the error led on my system - no matter how I set the ace address pin dip switches. I'm following the formatting guide straight from the "System ACE CompactFlash Solution" datasheet and have already reformatted my CF card (just in case) based on some other postings on this group -but I am still unable to get it to work. It's as if editing the xilinx.sys file by hand corrupts it or something? I've tried editing it in unix and under dos to make sure it's not something silly like ^M - but still no luck. Any suggestions would be appreciated! daveArticle: 131712
No secret, we do state that CBC is used (in a number of places). http://toolbox.xilinx.com/docsan/xilinx92/help/iseguide/mergedProjects/dkxilinx/html/pp_encryption_options.htm Simply: Select no encryption, generate bitstream. Select encryption, generate bitstream. Do a "diff." Now you see exactly where to start (and stop). AustinArticle: 131713
"Jeff Cunningham" <jcc@sover.net> wrote in message news:48168a98$0$19838$4d3efbfe@news.sover.net... > > My guess is that the first part is pre CES4 and the last part is post > CES4. You are basically right. Your second part is the full commercial silicon, which is also known as CES5. Your first part is probably CES1. I guess at that point Xilinx didn't have plans to release different versions of engineering samples, so they didn't include the number in the marking. Starting with CES2 the number was included in the marking. /MikhailArticle: 131714
Jeff, http://www.xilinx.com/support/answers/1067.htm Yes, that is the date code, the XX week of the YY year (for YYXX code) Note that the next line has the stepping code (if used) at the end). http://www.xilinx.com/support/answers/21605.htm Note that after CES4 comes stepping 0, then stepping 1, so the third line has a 1 at the end if the production stepping is 1 (nothing if it is a step 0, or the first production mask set). So, the second part is a stepping 0, whereas the first part is before CES1, 2, 3, or 4 markings, and is the very first engineering samples, plain ES, before we even had characterized C grade, or I grade. At least, that is what I am interpreting from the above answer records, and what I recall about V4 FX (which, quite frankly, was a terrible embarrassment. We have all vowed to never make those mistakes ever again!). So, the first marking you ever see is ES, always the lowest speed grade (effectively, no real speed grade has been verified yet), followed by CES, or IES grades, followed by (first) production step 0 (no number at end of third line), followed by subsequent steppings to fix subsequent errata that may be discovered. AustinArticle: 131715
Hello all, First of all, I understand the best way to have a solution is to start a webcase and I am doing it right now. But like normal days I need to solve this issue asap and thought to ask the list as well. I have a design with a CPLD, a Spartan3 (XC3S400) and a XCF02S memory on the JTAG chain. I cannot see the memory in the JTAG chain, only the CPLD and FPGA. When doing a Get Device ID on any of these devices it says there is a wrong ID. Before jumping on PCB or other cuases I have to say this design has already worked in the previous board spin. Though, there are two important differences: 1) The previous FPGA was an XC3S200. Same package. 2) The FPGA power supply is different. In the good (previous spin) board the 2.5V and 1.2V were from the 5V supply. Both 5V and 3V3 supplies are DC-DC converters from a single 28V power rail. In the new spin the 2.5V and 1.2V are from 3V3 supply (because 5V supply must be off some times during the equipment normal operation). The 3V3 ramp is about 700us long. I have found some data in the internet that suggest the VCC ramp could make the memory to do not run JTAG interface properly. Other documents talk about the Reset/OE pin that must rise fast or the internal data can shift some bits causing failure in the configuration (but it assumes the JTAG is okay). The board is ok. All connections were checked. The components seems ok and the memory was already replaced (just in case). The chain is: TDI- XCF02S-FPGA-CPLD-TDO. The XCF02S' TDO pin shows activity during the chain innitialization, like other devices's TDO pins. I am not sure if the problem is with VCC ramp, with 2V5/1V2 FPGA supply (somehow driving the memory nuts) or has to do with new FPGA densisty that could drive more current in the power-up and make a dip in the VCC. Actualy, there is a flat portion during the 3V3 ramp but no dip as far as I can see with my digital scope. Any hints on this case? Thanks, AugustoArticle: 131716
MM, Not sure is ES == CES1 (it may, or may not, be the same mask set). As soon as we start testing for the speed grade, we add the C to the ES. Before that, the ES alone indicates the part is untested at temperature. AustinArticle: 131717
Jeff, CES4 only applied to MGT's. No MGT's on FX12, no CESx markings at all. You have the ES first mask, and the production step 0 mask parts. No CES4 (pre or post). AustinArticle: 131718
Augusto, http://www.xilinx.com/support/documentation/customer_notices/advisory2003-07.pdf Is the only errata listed for this device. AustinArticle: 131719
1>uni-upload or uni-download,it works well.occasionally ,the NMI error is trigered if the PH credit is changed from (4)finite to (0)infinite . why can the PH credit become infinite? it is normal? 2>if upload and download simultaneity,the NIC is halt.it cann't send and receive any packet. e.g: The upload is progress,and if start to download a big size file ,the NIC will be halt. however.if the download size is about 20KB. it maybe be ok. if it is 1MB. it will be halt.the tx and rx will stop. it can be excluded the lnx driver issue. The MAC module is assumed ok. how to diagnose the issue from PCIE?Article: 131720
Austin , Thank you for useful informations , But i still have some questions about this subject ; in fact after doing the diff , i could localise the startCBC ( one word for command and four words for cbc value) followed by two commands (write to FDRI) ; after these two commands data is encrypted . My question is that if i take the first block of data ( 128 bits = 4 words)and i try to dercypt it with my key + startCBC (using Nist C AES 256 CBC) i don't find the clear data ! Also i would like to know if all zeros that we can see in the beginning of configurable data (clear bitstream) corresponds to the intialization of BRAM or not (?) Mario Bamboutcha ,Article: 131721
When I started with ROMs circa ISE 6.2 the COE thing wasn't working past some small number of values. Someone prompty directed me to infer the ROM and not use the core generator at all. The VHDL looks something like this: type i2c_array_type is array(natural range <>) of natural; constant i2c_data_array : i2c_array_type :=( 0,0,0 -- put your constants here ); signal i2c_bit_index0 : unsigned(2 downto 0); begin i2c_data1 <= i2c_data_array(i2c_dat_index0); You can use natural,integer,enumerated data,std_logic_vectors, or records to fit your design data type. All the simulation data will be visible and the ISE reports will tell you how many BRAMs were used. I don't think any deeper level of simulation will provide you more confidence. If you post your code, I'm sure we can help you debug some of the issues regarding conversions and the like. Brad Smallridge AiVisionArticle: 131722
"Kevin Neilson" <kevin_neilson@removethiscomcast.net> wrote in message news:fv7i38$69n6@cnn.xsj.xilinx.com... > > My question: what is the cleanest way to describe an FSM requiring > pipelining? As is usually the case...'it depends'. There are two basic approaches: 1. Add additional states to the FSM to match the latency of the newly pipelined operation. 2. Add a request/acknowledge handshake signal pair into and out of the FSM that controls movement to the next state. #1 is fairly straightforward, but as you're finding out gets to be a pain if you use this method exclusively instead of just for relatively simple cases that won't change. This method can also tend to create fairly cumbersome logic implementation as well (i.e. the state machine logic can get to become the critical timing path). For #2, with the request/acknowledge signals what you're doing is refactoring your logic and using signals to indicate when that process should wake up and when it has produced a result. Another way of looking at it is that you're 'subcontracting' or 'outsourcing' that hunk of logic. In the example you gave the multiply/add operation is the function that you're outsourcing. From the perspective of the state machine then it simply needs to tell this other hunk-o-logic when to start (i.e. request) and the hunk-o-logic in turn needs to tell the FSM when it has completed (i.e. acknowledge). This basic approach scales very well and is generally tolerant of further changes in the actual latency. Using your multiply/add example, you might at first decide to have one stage of latency (registering the inputs) and then later decide to make it three (register, inputs, multiply, and sum). The request/acknowledge signal *interface* between the hunk-o-logic and the FSM does not need to change, nor does the FSM itself (unlike approach #1). All that does need to change is you add a couple more flops of delay to generate the acknowledge. As you find other critical timing paths you'll still need to figure out exactly which sub-functions need to be segregated out for pipelining, but once you've done this, the approach is the same: simply create a request/acknowledge pair to control that sub-function and tie those signals into the state machine. Put the source code for the logic needed to generate the acknowledge physically right by the hunk-o-logic function itself and it makes it easy to maintain as well. If the hunk-o-logic is complex enough, you might consider making it it's own entity/architecture. If not, maybe put it in it's own separate process (something I do to kind of break up the actual source code text into manageable sized pieces to make it easy to see what that bit does). In any case, what you're basically doing is adding a bit of hierarchy to your design whether it is formal (i.e. separate entities) or less formal (separate clocked process). Once you've physically segregated the stuff, you can probably also see that it wouldn't be that hard to parameterize it so that you could have generics select whether the latency in some fashion...but that's a bit off topic. The other thing to consider is whether the latency being introduced by this outsourced logic needs to be 'compensated for' in some fashion or is it OK to simply wait for the acknowledge. In some instances, it is fine for the FSM to simply wait in a particular state until the acknowledge comes back. In others you need to be feeding new data into the hunk-o-logic on every clock cycle even though you haven't got the results from the first back. In that situation you still have the req/ack pair but now the ack is simply saying that the request has been accepted for processing, the actual results will be coming out later. Now the hunk-o-logic needs an additional output to flag when the output is actually valid. This output data valid signal would typically tend to feed into a separate FSM or some other logic (i.e. 'usually' not the first FSM). The first FSM controls feeding stuff in, the second FSM or other processing logic is in charge of taking up the outputs and doing something with it. When you ponder on this approach some more, you will come to the realization that this signalling back and forth between various sub-processes boils down to simply managing data transfer. Once that realization has settled in, it is worthwhile to study existing data transfer techniques (I'd suggest Wishbone and Avalon, I prefer Avalon), decide for yourself which signalling scheme to use and stick to it, using that specification's naming/logic conventions and go from there and never look back at all the other possible ad-hoc ways of doing it. > Is there some sort of tool that will let me make a nice bubble diagram but > also indicate which operations need pipelined and will then generate the > proper synthesizable HDL? Altera's Quartus has a state machine machine viewer that can be exported for documentation if that's what you're looking for. Kevin JenningsArticle: 131723
wire [6:0] length; wire [11:0] addr; assign len_lte=((addr[11:2]+length)<=13'h400)?1'b1:1'b0; thxArticle: 131724
On Apr 29, 8:57 pm, "water9...@yahoo.com" <water9...@yahoo.com> wrote: > wire [6:0] length; > wire [11:0] addr; > > assign len_lte=((addr[11:2]+length)<=13'h400)?1'b1:1'b0; There's no reason for the terniary; relational operators are booleans. Just write assign len_lte = addr[11:2] + length <= 13'h400; That said, I don't think there's much you can do if you really need len_lte to be one for 'h400 as well. This variant is much cheaper: assign len_lt = addr[11:2] + length < 13'h400; as expressions like x < (1 << k) is always the same as saying that all but the lowest k bits must be zero (assuming everything is unsigned). *Maybe* this will be faster than the original formulation (let us know): wire [12:0] sum = addr[11:2] + length; assign len_lt = sum < 13'h400; assign len_eq = sum == 13'h400; assign len_lte = len_lt | len_eq; You may also see if assign len_lt = ~|sum[12:10]; makes a difference, but to a good synthesizer it should be the same. Tommy
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