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
fmostafa wrote: > is there > anything else i have to change Since it doesn't work, the answer is yes. I would check the static timing for Fmax > 66MHz as a start. -- Mike TreselerArticle: 134876
About two months ago I've started learning VHDL, CPLD and FPGA.
Right from the start I've choosen Spartan-3 (XC3S50) and
didn't look at Spartan-II because I wanted to use the latest chip.
Now I am making a board with 50 5V TTL inputs and idea was to use
the CPLD XC95144XL as a level translator...but I just don't like it.
So, now I am trying Spartan-II (XC2S50),
which is 5V tolerant, and I have 3 problems/issues:
1. when I start "Implement design", ISE complains:
"MapLib:95 - IBUF symbol "CLOCK1_IBUF" (output signal=CLOCK1_IBUF1)
is promoted to indicate the use of GCLKIOB site."
I have 7 clocks in my design and ISE gives me the same report
for 3 of them. What does it mean and what should I do about it?
It works fine on spartan-3.
2. when I start "Floorplan IO - Pre-Synthesis", ISE complains:
"ERROR:HDLParsers:3562 - pepExtractor.prj line 1
Expecting 'vhdl' or 'verilog' keyword, found 'work'."
(This I can fix with LOC attribute..)
3. for how long will Spartan-II be available?
Cheers
Article: 134877Jochen <JFrensch@harmanbecker.com> wrote: >We had an issue with a "ground bounce" (Spartan3 design) in the bank >containing the PCI-interface, which 'triggered' the asynchonous reset >of the PCI-core... > >Do you use async resets ? Yes. The design uses async resets. But it doesn't seem to affect the PCI core. The problem is always in the part with the statemachines. -- Programmeren in Almere? E-mail naar nico@nctdevpuntnl (punt=.)Article: 134878
Jonathan Bromley <jonathan.bromley@MYCOMPANY.com> wrote: >On Wed, 03 Sep 2008 22:33:14 GMT, nico@puntnl.niks (Nico Coesel) >wrote: > >>In some specific type of PCs (mostly server chassis) the design quits >>working right away or after a while. Some of the internal >>statemachines quit even when the option 'Safe implementation' is >>turned on. In most PCs (say 99.9%) the design works okay though. > >Random data point from the mediaeval era: I had almost identical >symptoms with a video processing card, about 15 years ago, in >ISA bus. I eventually tracked it down to glitches on the bus >reset line, so narrow that all the old-style ISA cards missed >it, but the fast-ish FPGAs on my board would sometimes see it. > >I don't suppose it's the same issue for you. But it's weird >how this kind of thing rears its head from time to time. Thanks, this sounds interesting. -- Programmeren in Almere? E-mail naar nico@nctdevpuntnl (punt=.)Article: 134879
Brian Drummond wrote:
> But it's only worth pushing on that rope for so long. Then concede
> defeat; save time and instantiate the primitive component directly.
Or use the portable template with one read and one write port.
-- Mike Treseler
Article: 134880On 2008-09-03, Nico Coesel <nico@puntnl.niks> wrote: > > In some specific type of PCs (mostly server chassis) the design quits > working right away or after a while. Many desktop-class systems don't check PCI parity at all. Maybe that's changing as logic gets cheaper, but I know I implemented a target that didn't output any parity at all which worked fine on the motherboards I had at home. It's possible that your "server" motherboards are checking parity, seeing an error and doing something that you did not anticipate with your state machine. Of course with your PCI-PCIe bridge the problem should be isolated from the motherboard, but I can't tell if it was involved when you saw the problem. -- Ben Jackson AD7GD <ben@ben.com> http://www.ben.com/Article: 134881
Ben Jackson <ben@ben.com> wrote: >On 2008-09-03, Nico Coesel <nico@puntnl.niks> wrote: >> >> In some specific type of PCs (mostly server chassis) the design quits >> working right away or after a while. > >Many desktop-class systems don't check PCI parity at all. Maybe that's >changing as logic gets cheaper, but I know I implemented a target that >didn't output any parity at all which worked fine on the motherboards I >had at home. > >It's possible that your "server" motherboards are checking parity, seeing >an error and doing something that you did not anticipate with your state >machine. > >Of course with your PCI-PCIe bridge the problem should be isolated from the >motherboard, but I can't tell if it was involved when you saw the problem. Well, the PCI core is behaving just fine. It is the 'PCI client' side which goes wrong in a particular area which has nothing to do with the PCI core directly. But I guess it doesn't hurt to put a counter on the PERR signal to make sure. Thanks for the hint. -- Programmeren in Almere? E-mail naar nico@nctdevpuntnl (punt=.)Article: 134882
On Sep 4, 9:53=A0am, Mike Treseler <mtrese...@gmail.com> wrote: > Brian Drummond wrote: > > But it's only worth pushing on that rope for so long. Then concede > > defeat; save time and instantiate the primitive component directly. > > Or use the portable template with one read and one write port. > > =A0 =A0 =A0 =A0 -- Mike Treseler ...but the need was for 2 write ports (and 2 associated read ports): a true dual-port RAMArticle: 134883
I'm looking into running uClinux on a Microblaze.. and I read that Microblaze alone uses up about 900 logic cells... not sure how many gates that equates to, but anyone venture a guess if a Spartan II (150k gates) with 16MB of RAM, 4MB Flash is enough to run uClinux?Article: 134884
John_H wrote:
> ...but the need was for 2 write ports (and 2 associated read ports): a
> true dual-port RAM
I would make an arbiter
to interleave the accesses on alternate cycles,
or redo the design to use a fifo.
There is no other portable way to infer
a full dpram.
-- Mike Treseler
Article: 134885I'm not sure that defining a safe state machine is always a good option. For example, what if he had designed his FSM to be safe, and that ended up hiding the fact that he was not properly handling initialization timing (reset vs configuration is moot in this respect; both have to be timed properly)? Perhaps during development, safe techniques should be turned off, such that the rest of the design can be tested, then turned back on for final test and production if needed. I learned the hard way, on my very first design, the hazards of not properly handling asynchronous inputs to state machines. In those days (PALs), we defined the binary state assignments on K-maps and ensured that destinations of transitions due to asynchronous inputs were always adjacent (single bit change). Given the scarcity of registers, this was the most efficient way to handle asynchronous inputs. Unfortunately with one-hot encodings, there are no adjacent states. AndyArticle: 134886
"David Brown" <david@westcontrol.removethisbit.com> wrote in message news:48bf9105$0$25395$8404b019@news.wineasy.se... > Jon Beniston wrote: >>> The choice of the GPL >>> for the OpenSparc is similar - it effectively restricts its use to >>> evaluation and academic work >> >> Not if they used the LGPL, it isn't. >> > > They use the GPLv2, not the LGPL. > > One other point that I did not mention earlier for both GPL'ed code and > LGPL'ed code is that it is perfectly possible to make and sell devices > that use GPL'ed IP - as long as *all* the IP in the device is GPL'ed. GPL, or equivalent license. The only requirement is the end user can build the system without paying someone for licenses. > > I think it is very reasonable to say that the bitstream for a single FPGA > device is a single "work", and that the license for that "work" is not > affected by the licenses of any other "work", including other FPGA designs > and software running on the FPGA, at least as long as you are talking > about a complete design with a specific interface. The GPL specifically excludes "mere aggregation ... on a volume of a storage or distribution medium" from consideration. But you don't have to fight that battle to determine reasonable use. The bitstream is a distribution medium. However, that alone does not release the conveyor from the GPL's terms. The real issue is conveying the work if the end user cannot examine the work, modify it, and build it into a working system. The presence of other licensed IPs precludes distributing the modified work. He would have to license the other IPs in order to build and distribute the system. This is relevant in manufacturing scenarios, where the "work" is typically incorporated into the ROM of the presumably commercial hardware product. The issue is not the distribution medium, but licensing terms for the other, more restrictive IPs. This has no consequence for the single user. He may freely compile the GPL'ed source into his own work, if he is otherwise able to do so. (Hmmm. The EDK is not free. Microblaze and MPMC are licensed for use with the EDK. Is this an issue for GPL terms? I think not, but that can be a discussion point.) Anyway... Genode specifically makes the distinction between open source and commercial use in their license terms. The bitstream aspect is not a special case for GPL, and does not introduce new difficulties. Genode's stated intent was that you may examine the work, extend it as you wish, and convey the changes if you like as an open source work. They address commercial licensing terms separately. LGPL is not suitable for their intents. By releasing under LGPL, they essentially relinquish their commercial rights, which they expressly wish to hold.Article: 134887
Kolja Sulimma wrote: (snip) > The work can't be only part of the bitstream, > because the parts can't be seperated easily. > The IP inside a bitstream has a much tighter coupling > than statically linked code has. I am not so sure. Maybe logically, but not necessarily legally. With some amount of work, you might be able to generate a bitstream not containing certain parts of the logic, and a bitstream that could be combined with it that would generate the final result. That might require more details of the bitstream than are normally available, but that doesn't mean it can't be done as far as the legal system is concerned. -- glenArticle: 134888
Jim Granville wrote: > langwadt@fonz.dk wrote: >> http://www.eetimes.com/showArticle.jhtml?articleID=210201176&cid=NL_eet >> http://www.patentstorm.us/patents/7391237/description.html > Patents often clearly fail many of the thresholds they are supposed to > pass, in part because the filing lawyers are motivated by the payment > and act of creating a patent. It is not helped either, that most > lawyers have no idea, or experience, of the item-field. > A patent is merely a license to litigate, It sounds somewhat like what motherboard designers with flash upgrade must also do, though the details will be different in each case. It seems likely that the patent makes sense for some particular case, but was written and approved more generally than it should have been. -- glenArticle: 134889
On 7=D4=C223=C8=D5, =CF=C2=CE=E74=CA=B134=B7=D6, lixia....@gmail.com wrote: > hi all, > I'm trying to partially reconfigure my device (XC2VP30 on XUP board) > through ICAP. I have my > > ICAP attached to OPB which is attached to MicroBlaze.In bitgen.ut file > I have set the value of mode pins (M2M1M0) to 1 (PULLUP). So it is not > set on 101 which is JTAG mode. The value of persist is NO.Initially my > OPB clock frequency is 25MHz .The system contains a hwicap, a > uartlite and mdm all attached to the opb. . I'm using EDK9.1. > > i tried to start with an exmaple xhwicap_srp_example.c, but even the > part of initialize can't go through;when using XHI_XC2VP30 instead of > HWICAP_DEVICEID ,the initialize seems success,but the return of > Xhwicap_DeviceRead() is "device is busy",so the following function > can't execute.In other word,the deviceread of icap can't sucess,and it > leads to device busy and the program hangs. > > Besides,i find out that the program hangs on the setting of RNC > register in the Xhwicap_DeviceWrite() function,but the size and offset > regiser can be set successfully, > I don't get what the problem is. > > In bitgen.ut file I have set the value of mode pins (M2M1M0) to 1 > (PULLUP). So it is not set on 101 which is JTAG mode,and perisit is > set to No.And on the borad ,the config mode controlled by sw9 is not > JTAG too. > > i don't know if there is something else need to be noticed? > > I really appreciate it if you could kindly help me out with it. > > Thanks a lot beforehand, > > lixia my problem is solved when i choose v1_00_b for the ip and v1_00_a for the driver. thank you for fatmas' reply!Article: 134890
On 7=D4=C223=C8=D5, =CF=C2=CE=E74=CA=B134=B7=D6, lixia....@gmail.com wrote: > hi all, > I'm trying to partially reconfigure my device (XC2VP30 on XUP board) > through ICAP. I have my > > ICAP attached to OPB which is attached to MicroBlaze.In bitgen.ut file > I have set the value of mode pins (M2M1M0) to 1 (PULLUP). So it is not > set on 101 which is JTAG mode. The value of persist is NO.Initially my > OPB clock frequency is 25MHz .The system contains a hwicap, a > uartlite and mdm all attached to the opb. . I'm using EDK9.1. > > i tried to start with an exmaple xhwicap_srp_example.c, but even the > part of initialize can't go through;when using XHI_XC2VP30 instead of > HWICAP_DEVICEID ,the initialize seems success,but the return of > Xhwicap_DeviceRead() is "device is busy",so the following function > can't execute.In other word,the deviceread of icap can't sucess,and it > leads to device busy and the program hangs. > > Besides,i find out that the program hangs on the setting of RNC > register in the Xhwicap_DeviceWrite() function,but the size and offset > regiser can be set successfully, > I don't get what the problem is. > > In bitgen.ut file I have set the value of mode pins (M2M1M0) to 1 > (PULLUP). So it is not set on 101 which is JTAG mode,and perisit is > set to No.And on the borad ,the config mode controlled by sw9 is not > JTAG too. > > i don't know if there is something else need to be noticed? > > I really appreciate it if you could kindly help me out with it. > > Thanks a lot beforehand, > > lixia my problem is solved when i choose v1_00_b for the ip and v1_00_a for the driver. thank you for fatma's reply!Article: 134891
On 5 sept, 00:05, benn <benn...@hotmail.com> wrote: > I'm looking into running uClinux on a Microblaze.. and I read that > Microblaze alone uses up about 900 logic cells... =A0not sure how many > gates that equates to, but anyone venture a guess if a Spartan II > (150k gates) with 16MB of RAM, 4MB Flash is enough to run uClinux? requirements (absolute minimal) MB-uClinux *microblaze *intc *timer *uartlite * 4M RAM (maybe 2 or even 1) MB + small (minimal) system does fit s2-150 but 16MB sounds like SDRAM so you need sdram controller ip as well if that together fits s2-150 i bet it is gonna be very tight AnttiArticle: 134892
MikeWhy wrote: > "David Brown" <david@westcontrol.removethisbit.com> wrote in message > news:48bf9105$0$25395$8404b019@news.wineasy.se... >> Jon Beniston wrote: >>>> The choice of the GPL >>>> for the OpenSparc is similar - it effectively restricts its use to >>>> evaluation and academic work >>> >>> Not if they used the LGPL, it isn't. >>> >> >> They use the GPLv2, not the LGPL. >> >> One other point that I did not mention earlier for both GPL'ed code >> and LGPL'ed code is that it is perfectly possible to make and sell >> devices that use GPL'ed IP - as long as *all* the IP in the device is >> GPL'ed. > > GPL, or equivalent license. The only requirement is the end user can > build the system without paying someone for licenses. > I don't think the GPL allows for mixing GPL code with "equivalent" licenses, although it is certainly possible (and not uncommon) to mix it with code that is dual licensed so that you are allowed to treat the code as pure GPL (the LGPL, for example, explicitly allows that). However, that's perhaps nitpicking. The point is, as you said, that the end user can view, modify, rebuild and distribute the code without other licenses (although they may have to pay a small handling fee to get the source code, and may have to pay for the tools). >> >> I think it is very reasonable to say that the bitstream for a single >> FPGA device is a single "work", and that the license for that "work" >> is not affected by the licenses of any other "work", including other >> FPGA designs and software running on the FPGA, at least as long as you >> are talking about a complete design with a specific interface. > > The GPL specifically excludes "mere aggregation ... on a volume of a > storage or distribution medium" from consideration. But you don't have > to fight that battle to determine reasonable use. The bitstream is a > distribution medium. However, that alone does not release the conveyor > from the GPL's terms. > The bitstream is not just the "distribution medium" - it is also the "program". It is the equivalent of the elf or exe file as well. (If you have code for two or more FPGA's in the same bitstream, then these are obviously "mere aggregates".) To be aggregates, you must be able to separate the parts, use them separately, and replace them separately. > The real issue is conveying the work if the end user cannot examine the > work, modify it, and build it into a working system. The presence of > other licensed IPs precludes distributing the modified work. He would > have to license the other IPs in order to build and distribute the > system. This is relevant in manufacturing scenarios, where the "work" is > typically incorporated into the ROM of the presumably commercial > hardware product. The issue is not the distribution medium, but > licensing terms for the other, more restrictive IPs. > That's certainly a major issue, yes. > This has no consequence for the single user. He may freely compile the > GPL'ed source into his own work, if he is otherwise able to do so. > (Hmmm. The EDK is not free. Microblaze and MPMC are licensed for use > with the EDK. Is this an issue for GPL terms? I think not, but that can > be a discussion point.) > IP and code that comes with the standard Xilinx tools will count as "standard system libraries", and can be freely used with GPL'ed code in the same way as software on Windows uses the windows headers, or software written in Python uses the Python libraries (which are not GPL'ed, but have their own open source license). Whether or not the Microblaze is a "standard system library" could certainly be discussed. It's that sort of thing that makes it so important to have an informal but clear "clarification statement" along with a license. For example, Linux has a statement making it perfectly clear that programs that use the Linux API are in no way "derived works", and are unaffected by the GPL in the kernel (there is no such statement surrounding binary drivers, and thus plenty of discussion there!). > Anyway... Genode specifically makes the distinction between open source > and commercial use in their license terms. The bitstream aspect is not a > special case for GPL, and does not introduce new difficulties. Genode's > stated intent was that you may examine the work, extend it as you wish, > and convey the changes if you like as an open source work. They address > commercial licensing terms separately. LGPL is not suitable for their > intents. By releasing under LGPL, they essentially relinquish their > commercial rights, which they expressly wish to hold. > Yes, I think the full GPL is the correct choice for Genode in this case, although as I said before I don't think the LGPL would be any different legally. However, since the LGPL is in many ways harder to understand (look at this thread here), the full GPL is a better choice here.Article: 134893
H. Peter Anvin wrote: > David Brown wrote: >> Petter Gustad wrote: >>> Why does Quartus run with lowest priority level (19) under Linux? It >>> also seems like if you nice quartus_sh to some higher priority when >>> you start it the sub-processes (like qartus_map etc) will still have >>> priority 19. I find this a little odd. Is there a reason for this? >>> >> >> I'd imagine the idea is that you can continue working with other >> programs while the long-running processes run in the background. >> Modern Linux kernels typically have schedulers that automate this >> (giving higher priority to short-running interactive processes), but >> there is no harm in running something like Quartus at low priority >> unless you are simultaneously running another process that tries to >> use all available processing time. > > It really hurts you if you have server machines with "cycle-scraper" > processes (often verification jobs) that administratively have lower > priority than Quartus. > > You want to be able to control this behaviour. > Yes, you should be able to control it - as you say, you may have several low-priority jobs that you want done in the background, and some are lower priority than others. I'd imagine that Altera have been thinking mainly of the common case running on an engineer's workstation rather than a server, but they could still have been more flexible. Of course, you could always get a multi-core cpu for your server - these jobs are seldom multi-threaded, so that would let you do both at once.Article: 134894
David Brown <david@westcontrol.removethisbit.com> writes: > some are lower priority than others. I'd imagine that Altera have > been thinking mainly of the common case running on an engineer's > workstation rather than a server, but they could still have been more > flexible. Altera is still into the mindset of one engineer working on one FPGA on his or hers PC. > Of course, you could always get a multi-core cpu for your server - > these jobs are seldom multi-threaded, so that would let you do both at > once. grep -c ^processor /proc/cpuinfo 8 :-) Petter -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail?Article: 134895
On Sep 4, 2:36=A0pm, Brian Drummond <brian_drumm...@btconnect.com> wrote: > On Thu, 4 Sep 2008 02:24:50 -0700 (PDT), Pablo <pbantu...@gmail.com> > wrote: > > >I am trying to use XST to create a "black box" from a VHDL core. The > >output NGC file fails when I try to include it in a Xilinx ISE design. > >Does anyone know the way to create a black box from a file.vhd? > > >best regards. > > First thing to check is that the output NGC file was synthesised without > I/O buffers on its internal ports. There are synthesis options for this. > > That would certainly cause it to fail when included in another design... > > - Brian ok. Thanks Brian.Article: 134896
On Sep 4, 5:05=A0pm, benn <benn...@hotmail.com> wrote: > I'm looking into running uClinux on a Microblaze.. and I read that > Microblaze alone uses up about 900 logic cells... =A0not sure how many > gates that equates to, but anyone venture a guess if a Spartan II > (150k gates) with 16MB of RAM, 4MB Flash is enough to run uClinux? If you know how many logic cells the Microblaze uses, why don't you just look at how many logic cells your FPGAs have??? Gate count is a level removed from reality both in the design and in the chip. So why translate into the domain of a poor measurement? RickArticle: 134897
On 5 sept, 15:53, rickman <gnu...@gmail.com> wrote: > On Sep 4, 5:05=A0pm, benn <benn...@hotmail.com> wrote: > > > I'm looking into running uClinux on a Microblaze.. and I read that > > Microblaze alone uses up about 900 logic cells... =A0not sure how many > > gates that equates to, but anyone venture a guess if a Spartan II > > (150k gates) with 16MB of RAM, 4MB Flash is enough to run uClinux? > > If you know how many logic cells the Microblaze uses, why don't you > just look at how many logic cells your FPGAs have??? =A0Gate count is a > level removed from reality both in the design and in the chip. =A0So why > translate into the domain of a poor measurement? > > Rick the gate count is sure ir relevant but the MB LC count is also :) he needs to build the system and check it out and change options to optimize this can not be calculated from datasheets AnttiArticle: 134898
On Sep 3, 3:43=A0pm, Kevin Neilson <kevin_neil...@removethiscomcast.net>
wrote:
> Here's an example. =A0These two counters operate in the same way:
>
> reg [7:0] count1=3D0, count2=3D0;
> always@(posedge clk)
> =A0 =A0begin
> =A0 =A0 =A0if (count1=3D=3D135) count1 <=3D 0;
> =A0 =A0 =A0else count1 <=3D count1 + 1;
> =A0 =A0 =A0if (count2>134) count2 <=3D 0;
> =A0 =A0 =A0else count2 <=3D count2 + 1;
> =A0 =A0end
>
> You can see that both counters are identical, but if synthesized
> according to the RTL, count2 will have a lot more logic and will be
> slower, because the > with synthesize a subtractor. =A0But it's just a
> waste of logic, because count2 will never have a value of 136 or
> greater
It's interesting when people forget the fundamental principles that
underly an implementation (in this case simple boolean logic) and/or
the hardware assist that may or not be available in a particular
device and then make claims that don't stand up.
The only way count2 would have a lot more logic as you say would be if
the targetted device had a hardware implementation of an equality
comparator but had to implement 'greater than' with logic.
Without such a hardware assist though, count2 will always synthesize
to either the same amount of logic or somewhat less logic than that
needed for count1 (usually it will be slightly less). Given a
programmable device that has to implement both ">" and "=3D" in logic,
all synthesis tools will eventually map these into the fundamental
boolean logic that describes this and optimize the implementation of
those equations. Using ">" allows for more optimizations since those
unreachable count values are then used to implement different boolean
equations to define the input to the flops that are less specific than
the one particular case being singled out for "=3D".
In any case, count1 and count2 should result in basically the exact
same amount of logic resources and performance. If not, then your
synthesis tool likely has a problem. Some example VHDL code is shown
below which describes the two different methods that you mentioned as
well as a third method which uses integers defined over the valid
counting range. Fitter results are in the comments. Using an integer
resulted in the same logic usage as ">"; logic resource usage for ">"
was always better than that for "=3D" (but not by much).
Take the example code I've provided out for a spin (or even the code
that you posted above) target some actual devices and see for yourself
that it doesn't much matter.
Kevin Jennings
**** Start of code ****
library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;
entity Cnt1 is
generic(
Bits: positive :=3D 24;
Max: positive :=3D 2**23+ 135);
port(
------------------------------------------------
-- Targetting a Cyclone II, Cnt1 synthesizes to:
-- Params Logic elements
-- =3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D
-- Bits=3D8, Max=3D135 12
-- Bits=3D24, Max=3D135 33
-- Bits=3D24, Max=3D2**23+135 34
------------------------------------------------
clk: in std_logic;
count: out std_logic_vector((Bits - 1) downto 0));
end Cnt1;
architecture RTL of Cnt1 is
signal count_int: unsigned(count'range) :=3D (others =3D> '0');
begin
process(clk)
begin
if rising_edge(clk) then
if (count_int =3D Max) then
count_int <=3D to_unsigned(0, count_int'length);
else
count_int <=3D count_int + 1;
end if;
end if;
end process;
count <=3D std_logic_vector(count_int);
end RTL;
library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;
entity Cnt2 is
generic(
Bits: positive :=3D 24;
Max: positive :=3D 2**23+ 135);
port(
------------------------------------------------
-- Targetting a Cyclone II, Cnt2 synthesizes to:
-- Params Logic elements
-- =3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D
-- Bits=3D8, Max=3D135 11
-- Bits=3D24, Max=3D135 32
-- Bits=3D24, Max=3D2**23+135 32
------------------------------------------------
clk: in std_logic;
count: out std_logic_vector((Bits - 1) downto 0));
end Cnt2;
architecture RTL of Cnt2 is
signal count_int: unsigned(count'range) :=3D (others =3D> '0');
begin
process(clk)
begin
if rising_edge(clk) then
if (count_int > (Max - 1)) then
count_int <=3D to_unsigned(0, count_int'length);
else
count_int <=3D count_int + 1;
end if;
end if;
end process;
count <=3D std_logic_vector(count_int);
end RTL;
library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;
entity Cnt3 is
generic(
Max: positive :=3D 2**23+ 135);
port(
------------------------------------------------
-- Targetting a Cyclone II, Cnt3 synthesizes to:
-- Params Logic elements
-- =3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D
-- Max=3D135 11
-- Max=3D2**23+135 32
------------------------------------------------
clk: in std_logic;
count: out natural range 0 to Max);
end Cnt3;
architecture RTL of Cnt3 is
signal count_int: natural range 0 to Max :=3D 0;
begin
process(clk)
begin
if rising_edge(clk) then
if (count_int > (Max - 1)) then
count_int <=3D 0;
else
count_int <=3D count_int + 1;
end if;
end if;
end process;
count <=3D count_int;
end RTL;
**** End of code ****
Article: 134899hi i want some help i m in my final year of avionics engg i have been give a project to develop a fpga based encryption module for voice comunication can u help me in it yusufil...@gmail.com wrote: > hi, > > I would like to implement a secure channel over an unsecure medium. > > mic(voice) => A/D conv =>digital, unsecure, unknown comm link => D/A > conv =>voice > analog Host A/D digital > "other side" > > I do not want to encrypt data at the device's digital side > because it is unsecure, and I dont know how to interfere digital data > I don not have access to embedded software, source code etc. > (maybe just after host A/D converter and emulating Host A/D converter > to device,,,maybe) and > every encryption algorithm implemented here can be broken at the other > side I guess. > > What I want to do is ; > > mic(voice) => A/D conv + cpld or fpga + D/A conv =>A/D conv => unknown > comm link > analog ecrypt + scramble digital data voice like > encrypted signal > > The Device will see voice freq signal and will transmit them through > channel as if they are real voices. > At this point adding some noise may help a lot. > a little bit noise may fool attackers but human still can understand > what is said. > > > questions: > > what is possible weakness of this system? > I am sure it can be still broken but > how easy to break it? > What kind of tools/approaches "they" are using ? > Is cpld enough for general data encryption? > (data is human voice so 8Kbps.) > encrytion should be easy so the hacking also.... > they: whatever you say > > thanks > > > yusuf
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