Re: KCPSM6 PicoBlaze: ¡Soft cores al poder!
Publicado: 10 May 2018, 07:32
quiero uno!!!!azesmbog escribió: У меня давно есть DE10 nano,
Forum to discuss about the ZX-Uno project
https://www.zxuno.com/forum/
quiero uno!!!!azesmbog escribió: У меня давно есть DE10 nano,
я когда-нибудь, может еще в этом году, буду приобретать себе еще один DE10nano:)))jepalza escribió: quiero uno!!!!
(traducción según Google:azesmbog escribió: В первоначальном ядре Galaksija был PicoBlaze, но он был сделан только для Spartan 3 и несовместим со Spartan 6.
Hlide Fremen Having a software virtual machine is quite common. What is it in question here is the reverse situation: executing micro-instructions through a hardware interpreter to reproduce a micro-coded 8-bit CPU (that is, a CISC one). While we may question about using that technic for creating an accurate cycle 486 processor, using it for 8086, Z80, 6502, etc. may be profitable because - well designed - you can save a lot of LE with having an accurate cycle reproduction. For instance, you could have a 6510 for a C64 and a 6502 for a 1541 inside the FPGA and still have a lot of place for addition. You could also fit a Z80 and an 8502 and other chips to make a C128. Obviously, I'm not saying it should be done as a replacement of the existing ones. I'm just saying they could be alternatives for cases where you may want to get more LE for additional features or for other FPGAs not regarding DE10-nano.
Por todo lo que he leido, el caso es que se tiene creada una CPU de 16 bits que ocupa muy poco espacio en la FPGA. Luego se hace un programa que utilice las instrucciones de esa CPU para implementar las intrucciones de otra CPU, por ejemplo la instrucción LD A,n del Z80, y así con todas las del Z80 con exactitud a ciclo de reloj. Para que esto funcione la CPU real debe ir mucho más rápida que la que emula, por ejemplo a 80 MHz la real para emular a otra de 4 Mhz a nivel de ciclo de reloj. Lo que se gana es el espacio que ocupa en la FPGA ya que la CPU de 16 bits + programa que emula instrucciones de 2ª CPU es mucho menor que el espacio que ocupa la 2ª CPU si se define de la forma tradicional dentro de la FPGA. Esto permite meter en una FPGA con "pocos" slices más CHIPS que si se definiesen de la forma tradicional. Al ocupar menos espacio se pueden meter funcionalidades que antes no cabrían por el tamaño de la FPGA en número de slices.nch escribió:¿Se puede conseguir lo mismo emulando por software que recreando mediante una fpga?
¿Qué limitaciones tiene cada método? En términos que los pueda entender
Dicho así, parece que son todo ventajas. ¿No tiene inconvenientes? ¿Se podría distinguir una fpga "pura" de otra "mixta" recreando el mismo sistema?desUBIKado escribió:Por todo lo que he leido, el caso es que se tiene creada una CPU de 16 bits que ocupa muy poco espacio en la FPGA. Luego se hace un programa que utilice las instrucciones de esa CPU para implementar las intrucciones de otra CPU, por ejemplo la instrucción LD A,n del Z80, y así con todas las del Z80 con exactitud a ciclo de reloj. Para que esto funcione la CPU real debe ir mucho más rápida que la que emula, por ejemplo a 80 MHz la real para emular a otra de 4 Mhz a nivel de ciclo de reloj. Lo que se gana es el espacio que ocupa en la FPGA ya que la CPU de 16 bits + programa que emula instrucciones de 2ª CPU es mucho menor que el espacio que ocupa la 2ª CPU si se define de la forma tradicional dentro de la FPGA. Esto permite meter en una FPGA con "pocos" slices más CHIPS que si se definiesen de la forma tradicional. Al ocupar menos espacio se pueden meter funcionalidades que antes no cabrían por el tamaño de la FPGA en número de slices.nch escribió:¿Se puede conseguir lo mismo emulando por software que recreando mediante una fpga?
¿Qué limitaciones tiene cada método? En términos que los pueda entender
Es que no hay implementación pura de un sistema. Un sistema electrónico tiene que responder a unas señales con otras en determinado tiempo y forma. Como lo hagas depende de ti.nch escribió: Dicho así, parece que son todo ventajas. ¿No tiene inconvenientes? ¿Se podría distinguir una fpga "pura" de otra "mixta" recreando el mismo sistema?