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
Anssi Saari <as@sci.fi> wrote: > For a soft CPU a RISC-V might be reasonable and a Linux port exists even > if it's very new. RISC-V is an instruction set but as I understand it, > there are loads of free implementations on Github. Do you know of any RISC-V cores on FPGA which are capable of booting Linux? There's loads of microcontroller-class cores, but not many larger ones. I've only seen Rocket, which is somewhat awkward to deal with, and LowRISC which is an older version of Rocket (those folks are at the forefront of suffering the pain of interfacing with Rocket). SiFive are shipping(ish) silicon with Rocket in it. There's also PULP and various CPUs from IIT Madras, but I'm not sure what state of completeness they're in. In our experience with BERI (which is a 100MHz 64 bit CPU with caches and MMU, but using the MIPS ISA and runs FreeBSD rather than Linux), it'll fit on a 115K Cyclone IV but nothing much smaller. TheoArticle: 160576
Theo Markettos <theom+news@chiark.greenend.org.uk> writes: > Do you know of any RISC-V cores on FPGA which are capable of booting Linux? I've got a virtex-7 board running Fedora on a quad-core 64-bit RISC-V. Is that big enough? ;-)Article: 160577
DJ Delorie <dj@delorie.com> wrote: > > Theo Markettos <theom+news@chiark.greenend.org.uk> writes: > > Do you know of any RISC-V cores on FPGA which are capable of booting Linux? > > I've got a virtex-7 board running Fedora on a quad-core 64-bit RISC-V. > Is that big enough? ;-) Which core are you using? I don't think the V7 comes in QFP ;-) TheoArticle: 160578
Theo Markettos <theom+news@chiark.greenend.org.uk> writes: >> I've got a virtex-7 board running Fedora on a quad-core 64-bit RISC-V. >> Is that big enough? ;-) > > Which core are you using? It's the sifive freedom unleashed core, the U500. > I don't think the V7 comes in QFP ;-) Nope.Article: 160579
DJ Delorie <dj@delorie.com> wrote: > > Theo Markettos <theom+news@chiark.greenend.org.uk> writes: > >> I've got a virtex-7 board running Fedora on a quad-core 64-bit RISC-V. > >> Is that big enough? ;-) > > > > Which core are you using? > > It's the sifive freedom unleashed core, the U500. So that's based on Rocket. Thus far I only know about Rocket and PULP's Ariane that are able to boot Linux. > > I don't think the V7 comes in QFP ;-) > > Nope. Shucks :) Might be over the OP's budget anyway... by a factor of 100. TheoArticle: 160580
Seem to get better results when using inferred data paths? E.g. letting the synthesis tools insert the multiplexers where they see fit gives better Fmax than laying out the datapath in complete detail. Also don't need to remember and code all the control signals for the muxes. Still code intermediate adders and such to keep the number of inferred carry chains down. Comments? Jim BrakefieldArticle: 160581
Dear J=C3=BCrgen, sorry for reviving this thread after all these years - but your mentioned e= Mail address is invalid meanwhile. So if you are still listening - did you find the searched disassemblers in = the last 18 years? I have found some pieces, so maybe they might be of interest for you too. AndreasArticle: 160582
The webinars are hosted by Aldec as follows: Thursday 26 April:=20 EU: 3:00 PM =E2=80=93 4:00 PM (CEST) : https://www.aldec.com/en/events/10= 12=20 US: 11:00 AM =E2=80=93 12:00 PM (PDT): https://www.aldec.com/en/events/10= 11=20 ----------- For an FPGA design we all know that the architecture =E2=80=93 all the way = from the top to the micro architecture =E2=80=93 is critical for both the F= PGA quality and the development time. It should be obvious to any experienc= ed designer that this also applies to the testbench.=20 Most FPGA designs are split into stand-alone modules =E2=80=93 for instance= for each of the FPGA external interfaces. In VHDL these modules are VHDL e= ntities, and they are normally accessed from a CPU via a standardized regis= ter interface, which acts as an abstraction layer. This abstraction allows = a safe and efficient control of the complete FPGA.=20 Such an approach should also be used for the verification environment - to = simplify the testbench architecture and the control of the interfaces. This= way the verification structure will mirror the design structure, allowing = the best possible overview, readability, maintainability and reuse.=20 There is however nothing even close to a standard on how to build the testb= ench architecture, how to access the verification components, how to contro= l them, or how to extend them for more complex functionality. =20 UVVM provides a very simple and powerful solution for all of this - and has= in fact standardized the testbench architecture, the microarchitecture of = the verification components and their command/status interface, a set of co= mmon commands, debugging support, etc. This makes it possible for the whole VHDL community to make verification co= mponents that have the same architecture, can be integrated the same way, d= ebugged the same way and controlled the same way. Thus, verification compon= ents may be shared easily within the VHDL community, allowing designers to = build their own test harness much faster than ever before =E2=80=93 using a= mix of their own and 3rd party VHDL verification components. Agenda: - Where is time spent and wasted - Basic testbenches using a good infrastructure - Mirroring the design architecture - Testbench, test harness, verification components - Test cases and sequencers, transactions and synchronization - Randomization and Functional Coverage - The ESA extensions - Live demo - Conclusion - Q&A This webinar will show how UVVM is standardising the VHDL testbench archite= cture and also present some of the most important UVVM extensions sponsored= by ESA (the European Space Agency)=20Article: 160583
It depends if you structure your design to allow it to be mapped to the features of the underlying hardware. If you do this well you can get optimal performance. If you do this poorly (e.g have a reset on an internal register that can't be reset) then you will be left scratching your head trying to work out why performance is poor.Article: 160584
On Thursday, April 26, 2018 at 5:27:19 AM UTC-5, Mike Field wrote: > It depends if you structure your design to allow it to be mapped to the features of the underlying hardware. > > If you do this well you can get optimal performance. If you do this poorly (e.g have a reset on an internal register that can't be reset) then you will be left scratching your head trying to work out why performance is poor. Am thinking there are two issues: Mapping to FPGA resources, which is always an issue. (and particular FPGA families differ on things such as resets) And best Fmax, where the packer and router have the interconnect delay info. My thinking is that the location and ordering of the mux inputs makes a significant difference. And, unless you are a Jan Gray type, the tools (ISE, Quartus, etc) can do a better job? (for the uninitiated, take a look at some real world routing on an FPGA) Jim BrakefieldArticle: 160585
Hello, I have used Xilinx core generator to synthesize a bram with width of 16 bit and depth of 80k, resulting a 17-bit address. Let's call them bram_data, and bram_addr. I am connecting the bram to PLB bus which has 32-bit address (Bus2IP_Addr) and 32-bit data (Bus2IP_Data). I am not sure how to connect those two together since I don't understand that if the address is not at the 32-bit boundary: (1) Does Bus2IP_Addr contains the requested address (0x2 for example), or the closest 32-bit boundary (0x0 for example). (2) Does Bus2IP_Data contains the data at 0x2, or data at 0x0 ? I have tried all the combinations I could think of but nothing seems to work. I would like to understand this before continuing debugging my code. thank you very much.Article: 160586
Does <= (reg) changes value at the same clk posedge or the next clk posedge in simulation ?Article: 160587
I'll ask Jan what his magic is and let you know :-) I feel it is usually better to work at the highest level of abstraction you= can, but always being sympathic to the lower levels. That way you have to dive into the lower levels less frequently to resolve = what in retrospect were trivial issues. Of course you have to dive to the low levels or read and understand lots an= d lots of documentation to get an appreciation of what is sympathic to the = lower levels. Experience has to be earned! Sometimes it is the smallest changes that can matter - using active high vs= active low signallimg, or registering a 'clear accumulator' flag so the re= gister can be absorbed into a DSP block. If you are aware of tham you can s= ave a lot of time. You see what patterns do or don't work, and only use the= ones that do=20 But of course, at the sharp end where absolute performance is needed in com= plex designs then carefully engineered datapaths may be needed. The tools a= re good, but are only tools. Mike.Article: 160588
On Saturday, 28 April 2018 03:03:47 UTC+12, jim.bra...@ieee.org wrote: > On Thursday, April 26, 2018 at 5:27:19 AM UTC-5, Mike Field wrote: > > It depends if you structure your design to allow it to be mapped to the= features of the underlying hardware. > >=20 > > If you do this well you can get optimal performance. If you do this poo= rly (e.g have a reset on an internal register that can't be reset) then you= will be left scratching your head trying to work out why performance is po= or. >=20 > Am thinking there are two issues: > Mapping to FPGA resources, which is always an issue. > (and particular FPGA families differ on things such as resets) >=20 > And best Fmax, where the packer and router have the interconnect delay in= fo. > My thinking is that the location and ordering of the mux inputs makes a s= ignificant difference. And, unless you are a Jan Gray type, the tools (ISE= , Quartus, etc) can do a better job? > (for the uninitiated, take a look at some real world routing on an FPGA) >=20 > Jim Brakefield A asked: "For a new moderately complex design, should I go for an engineered or infe= rred data path? (a.k.a. Should I initially trust the tools or not?)" Jan's reply was.... "IMO you should have the technology mapped solution in mind before you star= t coding -- then do a min effort bottom up implementation to emit that, whe= ther inferred or structurally instantiated. http://www.fpgacpu.org/log/aug0= 2.html#art =E2=80=A6 :-)" Pragmatic as always!Article: 160589
On Saturday, April 28, 2018 at 2:26:22 PM UTC-5, Mike Field wrote: > On Saturday, 28 April 2018 03:03:47 UTC+12, jim.bra...@ieee.org wrote: > > On Thursday, April 26, 2018 at 5:27:19 AM UTC-5, Mike Field wrote: > > > It depends if you structure your design to allow it to be mapped to t= he features of the underlying hardware. > > >=20 > > > If you do this well you can get optimal performance. If you do this p= oorly (e.g have a reset on an internal register that can't be reset) then y= ou will be left scratching your head trying to work out why performance is = poor. > >=20 > > Am thinking there are two issues: > > Mapping to FPGA resources, which is always an issue. > > (and particular FPGA families differ on things such as resets) > >=20 > > And best Fmax, where the packer and router have the interconnect delay = info. > > My thinking is that the location and ordering of the mux inputs makes a= significant difference. And, unless you are a Jan Gray type, the tools (I= SE, Quartus, etc) can do a better job? > > (for the uninitiated, take a look at some real world routing on an FPGA= ) > >=20 > > Jim Brakefield >=20 > A asked: >=20 > "For a new moderately complex design, should I go for an engineered or in= ferred data path? (a.k.a. Should I initially trust the tools or not?)" >=20 > Jan's reply was.... >=20 > "IMO you should have the technology mapped solution in mind before you st= art coding -- then do a min effort bottom up implementation to emit that, w= hether inferred or structurally instantiated. http://www.fpgacpu.org/log/au= g02.html#art =E2=80=A6 :-)" >=20 > Pragmatic as always! Better info than expected. Although it's from almost 16 years ago. Would be good to hear from the IP vendors who offer customizable CPUs: RPMs will presumably work for the CPU core. What about, say, NIOS or microBlaze with their many configuration options? Jim BrakefieldArticle: 160590
Sharing VHDL Verification Components (VVC) within the FPGA/VHDL community h= as previously been difficult because there was no standardised way of inter= facing to and controlling these VVCs. A solution on this challenge could ea= sily reduce the project verification time by 20 to 80%, and at the same tim= e improve the FPGA quality. The open source UVVM has over the last two years standardised the command i= nterface, integration, debugging and internal architecture of VHDL Verifica= tion Components and clearly shown that a standardisation was in deed both p= ossible and extremely efficient. Open source VVCs have been released for AX= I4-lite, AXI4-stream, Avalon MM, I2C, SPI, SBI, UART and GPIO, - showing ho= w easy it is to implement testbenches and write test cases using this stand= ardised methodology. Due to this standardisation, FPGA designers world-wide have recently starte= d asking for more cooperation on UVVM compliant VVCs inside the VHDL commun= ity. As this is actually the main intention behind standardising VVCs, we h= ave now decided to facilitate a Verification IP cooperation. For this purpo= se we have opened a new repository on Github for sharing VHDL VIP next to t= he UVVM repository. https://github.com/UVVM/UVVM_3rd_party_VIP This new repository is intended to link to any UVVM compatible Verification= IP; - VVC, BFM or other. We have chosen not to include any VIP directly in= side this repository, as all 3rd party VIP will be the property of and main= tained by the 3rd party company or designer. Any 3rd part VIP will automatically be UVVM compliant given that the design= ers have used the provided templates or scripts from UVVM. This has of cour= se the major benefit that all UVVM compliant VIP can be controlled and acce= ssed exactly the same way and that they will work together. There is howeve= r no way we can guarantee the functionality of the DUT interface/protocol h= andled by 3rd party VVC or BFM designers, so this will be the full responsi= bility of the VIP provider. Any question regarding the VVC should therefore= be addressed to this provider. Bitvis will not qualify any 3rd party VIP, = but we assume the community will very soon give useful feedback. Open source Verification IP is great, and UVVM with its provided BFMs and V= VCs are all open source and free, - but we also welcome commercial VIP and = will link to this in the same way as open source. It is important for VHDL = designers to get the full overview of what is available, and it is up to th= em to decide whether a commercial VIP is ok. All commercial aspects must be= handled directly between the buyer and the seller. Bitvis has no role in t= his. Note that even if UVVM has standardised the VHDL testbench architecture for= efficient verification, you may still pick only the parts you like. Thus y= ou can pick only a single BFM or VVC from UVVM if you like, and use this in= your testbench together with your own and 3rd party verification IP. We now really hope that the VHDL community will use this opportunity to mak= e us all more efficient. Have a look at this on Github and start the proces= s :-) (This article was also published on LinkedIn. Articles there may also inclu= de figures, which sometimes is very useful... =20 https://www.linkedin.com/pulse/sharing-vhdl-verification-ip-espen-tallaksen= /)Article: 160591
On Saturday, 28 April 2018 09:47:42 UTC+8, promach wrote: > Does <= (reg) changes value at the same clk posedge or the next clk posedge in simulation ? all of the usage of non-blocking assignment to a value (the type of it must be 'reg')in always block will lead to the value-changed in the next posedge or negedge of clk.Article: 160592
I have a small design flaw with a new sensor, ICM20948, into a PI device. I= need to make the SDA bidirectional and level shift SCL, int, and fsync. Vo= ltage level on the sensor board is 1.8V the PI is 3.3V. I have CPLD hardwar= e that I would like to use to make the bidirectional level shifted SDA as w= ell as level shift the other three. The VHDL behavior is as simple as: begin enable <=3D '1' when DIR =3D '1' else '0'; I2C(0) <=3D SCL; I2C(1) <=3D SDA when enable =3D '0' else 'Z'; SDA <=3D I2C(1) when enable =3D '1' else 'Z'; end Behavioral; I have used this before in another I2C without failure. The hardware seems = to be performing the bidirectional communication, but all logic is a ~3.3V = level. The CPLD is a Xilinx XC2CA64 with the 1.8V I2C pins on 11 and 13 and the 3.= 3V I2C and ancillary pins on 15, 16 and 17. The UCF is as follows: NET "I2C(0)" LOC =3D "11" ; #SCL1V8 NET "I2C(0)" IOSTANDARD =3D "LVCMOS18" ; NET "I2C(1)" LOC =3D "13" ; NET "I2C(1)" IOSTANDARD =3D "LVCMOS18" ; #SDA1V8 NET "SCL" LOC =3D "17" ; #PI side NET "SCL" IOSTANDARD =3D "LVCMOS33" ; #=20 NET "SDA" LOC =3D "15" ; #PI side NET "SDA" IOSTANDARD =3D "LVCMOS33" ; # NET "DIR" LOC =3D "16" ; #PI side NET "DIR" IOSTANDARD =3D "LVCMOS33" ; #Article: 160593
Having taken a closer look at the XAPP785 I have a hardware issue on my board. Both the VCCIO1, pins 58 and 38, are driven by 3.3V as well as VCCIO2, pins 98, and 88.Article: 160594
nobody <cydrollinger@gmail.com> wrote: > Having taken a closer look at the XAPP785 I have a hardware issue on my > board. Both the VCCIO1, pins 58 and 38, are driven by 3.3V as well as > VCCIO2, pins 98, and 88. As a general rule, while you can (have to) set IO voltages in the FPGA software you still have to wire the bank VCC pins to the right voltage rail. I'm not aware of any FPGAs which can dynamically switch bank voltages. TheoArticle: 160595
Hi there, I am trying to implement a CAN sniffer on an Altera DE2-115 evaluation boar= d with the Terrasic AD/DA data conversion card (High Speed Mezzanine Card (= HSMC) via SMA. I am using two A/D channels for CAN_H and CAN_L bus signals. Before testing it with real CAN signals I want to make sure that the connec= tion is right in terms of voltage swing, differential termination and peak-= to-peak voltage. If I got it right I expect a voltage swing of about 1 volt= on the CAN_H and CAN_L signal, whereas the input characteristics for the d= ata conversion card say something about 0.5V. But I am not sure if I unders= tood it correctly. Could somebody please verify, unfortunately I am no expert in analog electr= onics. Any help is highly appreciated. Regards, RyoArticle: 160596
On Tuesday, May 8, 2018 at 10:59:21 AM UTC-4, nobody wrote: > I have a small design flaw with a new sensor, ICM20948, into a PI device.= I need to make the SDA bidirectional and level shift SCL, int, and fsync. = Voltage level on the sensor board is 1.8V the PI is 3.3V. I have CPLD hardw= are that I would like to use to make the bidirectional level shifted SDA as= well as level shift the other three. >=20 > The VHDL behavior is as simple as: >=20 > begin >=20 > enable <=3D '1' when DIR =3D '1' else '0'; > I2C(0) <=3D SCL; > I2C(1) <=3D SDA when enable =3D '0' else 'Z'; > SDA <=3D I2C(1) when enable =3D '1' else 'Z'; >=20 > end Behavioral; >=20 > I have used this before in another I2C without failure. The hardware seem= s to be performing the bidirectional communication, but all logic is a ~3.3= V level. This is not a problem really. The data line should be open collector which= is what I2C is intended to use. I believe SDA is the 3.3 volt I2C data li= ne and I2C(1) is the 1.8 volt I2C line. Your code should be written as bel= ow.=20 enable <=3D '1' when DIR =3D '1' else '0'; =20 -- This is redundant, unless you expect DIR to be some invalid state like '= Z', 'U', etc., it should be sufficient alone.=20 I2C(0) <=3D '0' when SCL =3D '0' else 'Z'; I2C(1) <=3D '0' when enable =3D '0' and SDA =3D '0' else 'Z'; SDA <=3D '0' when enable =3D '1' and I2C(1) =3D '0' else 'Z'; Now your outputs will *not* be driven high by the FPGA at any time other th= an possibly for a brief moment at a transition which can be good for speed.= This will be a race condition so may not happen. If you want to force a = delay to enable a drive to '1' on transitions of the data or clock line you= can set timing constraints to assign a max delay from clock to output for = the data and a minimum delay from clock to output for the enable signal. Y= ou will also need to bracket it the other way to prevent the drive time fro= m being too long, so min/max each delay to workable times. I've never trie= d doing this, so it may not be as easy as it sounds. Better might be a dif= ferential time delay... ?=20 Rick C.Article: 160597
On Sunday, April 1, 2018 at 4:49:58 PM UTC-4, mctuv...@gmail.com wrote: > On Sunday, April 20, 2003 at 6:30:57 AM UTC-4, Ian Hickey wrote: > > Does any manufacturer make a very small programmable logic device (with > > FLASH storage) is say a SOIC-8 or similar. > >=20 > > It's for a small home project that only has one output and only one inp= ut > > (plus CLK) > >=20 > > Thanks in advance. > >=20 > > Ian >=20 > I know this is many years since the original question, but... > ...Times, they are a changin'... > Here is an under $2 FPGA that sports 11 I/O pins in a tiny 4x4 BGA packag= e (16 pins total). > https://www.digikey.com/product-detail/en/lattice-semiconductor-corporati= on/ICE40UL1K-SWG16ITR50/220-1960-1-ND/5129490 Yes, Lattice has been introducing a number of low pin count and medium pin = count devices, but they are all in very fine pitch BGA packaging. Great fo= r high volume manufacturing, but sometimes difficult for medium volume work= and near impossible for low volume, hand assembly.=20 Rick C.Article: 160598
On 08/05/2018 15:59, nobody wrote: > I have a small design flaw with a new sensor, ICM20948, into a PI device. I need to make the SDA bidirectional and level shift SCL, int, and fsync. Voltage level on the sensor board is 1.8V the PI is 3.3V. I have CPLD hardware that I would like to use to make the bidirectional level shifted SDA as well as level shift the other three. > > The VHDL behavior is as simple as: > > begin > > enable <= '1' when DIR = '1' else '0'; > I2C(0) <= SCL; > I2C(1) <= SDA when enable = '0' else 'Z'; > SDA <= I2C(1) when enable = '1' else 'Z'; > > end Behavioral; > > I have used this before in another I2C without failure. The hardware seems to be performing the bidirectional communication, but all logic is a ~3.3V level. > > The CPLD is a Xilinx XC2CA64 with the 1.8V I2C pins on 11 and 13 and the 3.3V I2C and ancillary pins on 15, 16 and 17. The UCF is as follows: > > NET "I2C(0)" LOC = "11" ; #SCL1V8 > NET "I2C(0)" IOSTANDARD = "LVCMOS18" ; > NET "I2C(1)" LOC = "13" ; > NET "I2C(1)" IOSTANDARD = "LVCMOS18" ; #SDA1V8 > > NET "SCL" LOC = "17" ; #PI side > NET "SCL" IOSTANDARD = "LVCMOS33" ; # > NET "SDA" LOC = "15" ; #PI side > NET "SDA" IOSTANDARD = "LVCMOS33" ; # > NET "DIR" LOC = "16" ; #PI side > NET "DIR" IOSTANDARD = "LVCMOS33" ; # Level shifting bidirectional signals is not a trivial thing to do. Agree with Rick's post where the output should either be pulled low of Hi-Z. What is wrong with the classic way of doing it as per: https://www.nxp.com/docs/en/application-note/AN10441.pdf The SCL may also need to be truly bidirectional if there is any device clock-stretching. -- Mike Perkins Video Solutions Ltd www.videosolutions.ltd.ukArticle: 160599
On Sunday, May 20, 2018 at 12:21:28 PM UTC-4, Mike Perkins wrote: > On 08/05/2018 15:59, nobody wrote: > > I have a small design flaw with a new sensor, ICM20948, into a PI devic= e. I need to make the SDA bidirectional and level shift SCL, int, and fsync= . Voltage level on the sensor board is 1.8V the PI is 3.3V. I have CPLD har= dware that I would like to use to make the bidirectional level shifted SDA = as well as level shift the other three. > >=20 > > The VHDL behavior is as simple as: > >=20 > > begin > >=20 > > enable <=3D '1' when DIR =3D '1' else '0'; > > I2C(0) <=3D SCL; > > I2C(1) <=3D SDA when enable =3D '0' else 'Z'; > > SDA <=3D I2C(1) when enable =3D '1' else 'Z'; > >=20 > > end Behavioral; > >=20 > > I have used this before in another I2C without failure. The hardware se= ems to be performing the bidirectional communication, but all logic is a ~3= .3V level. > >=20 > > The CPLD is a Xilinx XC2CA64 with the 1.8V I2C pins on 11 and 13 and th= e 3.3V I2C and ancillary pins on 15, 16 and 17. The UCF is as follows: > >=20 > > NET "I2C(0)" LOC =3D "11" ; #SCL1V8 > > NET "I2C(0)" IOSTANDARD =3D "LVCMOS18" ; > > NET "I2C(1)" LOC =3D "13" ; > > NET "I2C(1)" IOSTANDARD =3D "LVCMOS18" ; #SDA1V8 > >=20 > > NET "SCL" LOC =3D "17" ; #PI side > > NET "SCL" IOSTANDARD =3D "LVCMOS33" ; # > > NET "SDA" LOC =3D "15" ; #PI side > > NET "SDA" IOSTANDARD =3D "LVCMOS33" ; # > > NET "DIR" LOC =3D "16" ; #PI side > > NET "DIR" IOSTANDARD =3D "LVCMOS33" ; # >=20 > Level shifting bidirectional signals is not a trivial thing to do. >=20 > Agree with Rick's post where the output should either be pulled low of Hi= -Z. >=20 > What is wrong with the classic way of doing it as per: > https://www.nxp.com/docs/en/application-note/AN10441.pdf >=20 > The SCL may also need to be truly bidirectional if there is any device=20 > clock-stretching. Your point is well taken. There isn't much chance of clock stretching bein= g used though as some number of I2C masters don't implement it. I would be= more concerned with proper management of the direction control signal. =20 In the app note you point to they don't seem to compensate for the loss in = voltage across the source to gate. So while there are pullups on both side= , the active drive from either side won't drive the full range and in fact = may be very cramped by the 1.8 volt power supply. If this bus isn't using = the fast bit rate I guess that won't be a problem.=20 Rick C.
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