Dock, vad för krav ställs på signalerna in/ut för att de ska vara kompatibla med "variable"? Måste man ha signed / unsinged eller hur funkar det då? Det är inget speciellt med typerna på en variabel, samma regler gäller som om du skulle använt en signal. Mao, om du t.ex. har en unsigned i...

En minimal inflikning, det är lite missvisande att säga att variables inte är applicerbara vid pipelining, det går alldeles utmärkt att använda de vid detta. Exempelvis så här: library ieee; use ieee.std_logic_1164.all; use ieee.numeric_std.all; entity test is port( clk : in std_logic; a : in std_lo...

Som du märkte så kopplar ISE dina portar på din modul till IO, varför ISE gör sådant när man inte explicit ber den om det har irriterat mig ett antal gånger. Men för att kunna få ett mått på ungefär hur mycket en modul drar måste man ändå koppla det till något verkligt för att få vettiga siffror. Om...

Varför måste det vara just nåt av de två alternativen?
Att en av motiveringarna är PR får man väl anta, men varför antar du att PRen måste vara riktad för en kommande modell?

Jo, det är riktigt intressant att ett företag tar steget att släppa sin hårdvara öppen, förhoppningsvis får vi se mer av sådant framöver.
Jag har ett de0 nano som de har gjort en referensdesign för, men jag har inte kommit mig för mer än att testa att bygga projektet.

TomasL skrev:I2C är svårt att själv realisera i hårdvara, då det är mycket timing och speciella start/stoppsekvenser inblandade.

Svårt? naah, svårare möjligtvis, men *så* komplicerat är det inte.

Jag har lite svårt att följa med i alla förkortningar, t.ex. PCHB = PC High Byte?
Hursomhelst verkar det verkligen bakvänt om en branch skriver över accumulatorn.
Och, tar det 10 klockcycler för att utföra en branch?(!)

Så, för att vara envis, undrar jag nog mest om tillvaratagande av carry samt inskiftning av 0:or från höger (ASL) respektive 0:or från vänster (ASR) räcker för att mjukvarumässigt kunna lösa MUL/DIV (om än något mindre klockcykel-effektivt). Ja, och det var just detta som mjukvaran som du satt och ...

Anledningen till detta är dels att jag bara "behärskar" grind-cad (ECS) dels är mycket osäker på hur MUL/DIV kan implementeras. Verilog/VHDL är i stort sett bara grindar i text-form, så jag tycker inte det borde vara så mycket jobb för dig att överföra dina grind-kunskaper till det. Dessu...

I mina öron låter det lite som du försöker anpassa ett problem till en färdig lösning du har. I det här fallet, du saknar MUL/DIV och då funderar du på om du kan modifiera problemet till att inte behöva MUL/DIV genom att överslagsberäkna. Detta kommer givetvis ge ett fullkomligt ointressant resultat...

Jo, jag håller med, bättre är ju att organisera sin kod så att .o filerna blir vettiga istället då.

Det gör inte vi heller, vi enumrerar istället, då makron bara skapar problem [...] enum är bra, men min mening är att de passar endast för konstanter i följande ordning. Dvs, för t.ex. bit-definitioner eller adress-definitioner ser jag hellre en macro definition. #define SOMEPERIPHERAL_SOMEREGISTER...

Den (avr-ld) länkar in hela de objekt-filer (.o) som finns i lib-filen (.a) om man använder något från objekt-filen. Man bör alltså ha orelaterade delar i olika objekt-filer annars tas rubbet med. Detta gäller förstås inte om man använder LTO (Link Time Optimization), men det är relativt nytt och k...

Nja, håller inte med dig. Det är inte fel att förklara vad koden gör, det blir oerhört mycket tydligare då, dessutom, så kan man faktiskt skilja mellan vad den bär göra och vad den gör. Jag håller med, men det beror ju på vilken nivå du kommentarar vad koden gör. Kommentarer som beskriver saker man...

Jag skulle snarare gissa att det i såfall berodde på bristande kunskap från din sida om något...